Celestin Apprentice 5/Apprentice-Release5.iso/Information/THINK C Digest/1992/92-08

Text File | 1995-12-31 | 167KB | 4,542 lines

Path: ucivax!gateway
From: [e-mail] (Tng Tai Hou)
Subject: Re:  Smooth Animation & GNE/WNE - Is it possible?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 1 Aug 92 02:27:06 GMT

This great. Please post your code and summaries.
It would help the net a great deal.

Thanks.

Tai Hou
Singapore










Path: ucivax!gateway
From: [e-mail] ("Jamie R. McCarthy")
Subject: Re: Smooth Animation & GNE/WNE - Is it possible?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Tom Johnson" at Jul 31, 92 8:57 pm
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 60
Date: 1 Aug 92 16:44:39 GMT

> I've got the drawing sync'd to a VBL task and everything works great in a
> situation like this:
>
>   do {
>         DrawNextFrame();
>      } while (!Button());
>
> of course.  But when I put it into a real event loop:
> [code removed]
> I get all sorts of little starts/stops/pauses in the animation, as the mac
> gives time to background processes.  And it's certainly not acceptable for
> a fast arcade-style game.
>
> How do other game authors handle it?  Do you not give time to bkgnd processes?
> Just let downloads timeout?  Or is there some simple idea that's gone by
> me completely?

Well, there's no easy way around it.  If you need ten minutes of solidly
smooth animation at a constant 20 fps, then you're simply not going to
be able to call WNE.

However, there can be ways around it if your requirements are a little
less stringent.  And it's very nice to know that downloads can go on
while playing, so giving time to background processes _is_ a goal worth
striving for.

Start from the assumption that your game takes priority, and work your
way towards being polite.  The first step is to not call WNE every time
through the event loop.  There's no reason to call it more frequently
than ten times a second.  And you can probably do just fine calling it
only once or twice a second.

(Keep in mind, though, that WNE only gives time to _one_ background
process at a time.  The worst-case scenario would be when the user has
twenty apps running, one of which is downloading with Kermit (which
requires confirmation after each send) in 128-byte packets.  If you call
WNE once a second, the download will proceed at 128 bytes every twenty
seconds.)

My animation, for example, doesn't have a constant frame rate.  I've set
it up to hog the CPU whenever an frame needs to be displayed within the
next two ticks, and to drop into the main event loop whenever the next
frame is three or more ticks away.  There's also an override, so that it
will never go more than n seconds without dropping into the main event
loop.  (I have n set at 3, but it doesn't work well for 5-second video
clips.  I think I'm going to change it so that it will initially go for
ten seconds without calling WNE, and then require the call every three.)

> This is just a little throw away freeware
> game, so I'm trying to get as much done as I can as quickly as possible. Has
> anyone ever written a sample arcade game and given away the source? Something
> I could base mine upon?

Ingemar Ragnemalm has written a Sprite Animation Toolkit that was in
preliminary testing last I knew.  You might want to contact him and get
ahold of it.
--
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 The essence of OOP:  "After some hacking, I finally got the program to
 work, but I'm still not sure why."  - David Marcovitz ([e-mail])










Path: ucivax!gateway
From: [e-mail] (Dana S Emery)
Subject: Re: Smooth Animation & GNE/WNE - Is it possible?
Message-ID: <[e-mail]>
In-Reply-To: Your message <[e-mail]> of 1 Aug 92
 16:44:39 GMT
Content-Type: TEXT/plain; charset=US-ASCII
Newsgroups: fa.think-c
Lines: 13
Date: 1 Aug 92 23:20:08 GMT

Rather than make presumptions about what the user wants you to do, why not give
the user a chance for some input? decide on a strategy for moderating your games
hogishness, and have a preference dialog for its parameters.

You really cant outguess what your users will prefer here, some will want to
game at full bore, others might be killing time during some other lengthy but
critical task.

The studly app wins reviews and influences buyers when it shows such
flexibility.

Dana S Emery <[e-mail]>











Path: ucivax!gateway
From: [e-mail] (Tom Johnson)
Subject: Re: Smooth Animation & GNE/WNE - Is it possible?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Jamie R. McCarthy" at Aug 1, 92 4:44 pm
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 16
Date: 2 Aug 92 00:59:06 GMT

Hi Jamie-

This is going to be a fast arcade-type game, but I think I can throw in a
WNE perhaps during explosions or something.  Thanks for your ideas.  I may
have some more questions about your method, when I'm thinking a bit more clearly
(only a few hours of sleep last night).

>
> Ingemar Ragnemalm has written a Sprite Animation Toolkit that was in
> preliminary testing last I knew.  You might want to contact him and get
> ahold of it.

Sounds interesting.  Do you have an email address?

Thanks-
  Tom










Path: ucivax!gateway
From: [e-mail] (Tom Johnson)
Subject: Re: Smooth Animation & GNE/WNE - Is it possible?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Dana S Emery" at Aug 1, 92 11:20 pm
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 6
Date: 2 Aug 92 00:59:07 GMT

Thanks Dana

I like the idea.  I think I'll put a "niceness" control in the preferences
and let people choose.

Tom










Path: ucivax!gateway
From: [e-mail] (Juri Munkki)
Subject: WaitNextEvent in games
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 24
Date: 2 Aug 92 01:01:23 GMT

I'm soon going to release the source code for what is known as
"STORM". I guess the think-c archives might be a nice central
distribution site for them. STORM (I really should call it
Arashi, since that's the new name, except that I didn't have
the time and energy to rewrite the title animations completely)
uses GetNextEvent and still maintains a 20 frames per second
animation rate even under system 7.0 with Finder running.

Note that open control panels use huge amount of background
time. Terminal programs and other such programs also usually
require some background time. Since the user can fairly easily
control the amount of background activity, I prefer giving
time to other processes.

Ben Haller (the author of Solarian) has the opposite approach
and he uses the OS event manager. The OS Event manager does not
give time to other processes.

A compromise might be in order. You could let the user choose
how often background time is given and use the OS event manager
for getting actual event information.

    Juri Munkki
    [e-mail]










Path: ucivax!gateway
From: [e-mail] ("David A. Denboer")
Subject: Modeless Dialogs
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 25
Date: 2 Aug 92 05:00:09 GMT

I post this again, because it is very important that I get it to work this
week.  When using modeless dialogs in THINK C (created in ResEdit), THINK C
displays the wrong type of window (It displays a ZoomDocProc when I want a
NoGrowDocProc)  To post the dialog on the screen, I use :
if (gModelessDialog == NIL) {
        gModelessDialog = GetNewDialog(rEnterDialog,NIL,(WindowPtr) -1);
    }

    SelectWindow(gModelessDialog);
    SetPort(gModelessDialog);
    ShowWindow(gModelessDialog);

Now the window type is defined properly in ResEdit, and the same resource works
fine from THINK Pascal.

Any suggestions?

--

David  A.  den Boer
Musi Computer Products
Macintosh Users Show Intelligence

[e-mail]











Path: ucivax!gateway
From: [e-mail] ("David A. Denboer")
Subject: QuickTime programming
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 31
Date: 2 Aug 92 10:07:16 GMT

When using THINK C 5.02 for QuickTime programming, I have a few problems.
I am trying to use the standard controller for viewing my movies, but I
can't get the controller to properly update itself.

I put the statement MCIsPlayerEvent in my mainloop like so:

while (!gQuit) {
        gotEvent = WaitNextEvent(everyEvent, &theEvent, MAXLONG, cursorRgn);
        MoviesTask(theMovie,0);
        MCIsPlayerEvent(myMovieController, &theEvent);
        if (gotEvent) {
                if (theMovie != nil)
                        DisableItem(GetMHandle(mFile), iPlay);
                HandleEvent(&theEvent);
}

But the controller never gets updated.  It just stays right at the beginning
of the movie, or moves just a little at the beginning of the movie.

Am I calling this wrong, or should I be calling it at a different place in
my program.

Any Help would be greatly appreciated,
--

David  A.  den Boer
Musi Computer Products
Macintosh Users Show Intelligence

[e-mail]











Path: ucivax!gateway
From: [e-mail] (darin s morley)
Subject: LZW Compression Revisited
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 38
Date: 3 Aug 92 19:50:36 GMT

I'm responding to a posting which I saw here a few weeks ago about the LZW
compression algorithm. I came across some interesting legal information on it
this past weekend. As some of you may know, the TIFF raster image format
optionally supports LZW compression. At least it did. While reading through
Revision 6.0 of the TIFF format I came across this:

"When LZW compression was added to the TIFF specification, in Revision 5.0, it
was thought to be public domain. This is, apparently, not the case.

"The following paragraph has been approved by the Unisys Corporation:

"'The LZW compression method is said to be the subject of United States patent
number 4,558,302 and corresponding foreign patents owned by the Unisys
Corporation. Software and hardware developers may be required to license this
patent in order to develop and market products using the TIFF LZW compression
option. Unisys has agreed that developers may obtain such a license on
reasonable, non-discriminatory terms and conditions. Further information can
be obtained from: Welch Licensing Department, Office of the General Counsel,
M/S C1SW19, Unisys Corporation, Blue Bell, Pennsylvania, 19424.'

"Reportedly, there are also other companies with patents that may affect LZW
implementors."

        -- _TIFF_Revision_6.0_, Section 13: LZW Compression, p. 57.

Names of the other companies were not provided, so your guess is as good as
mine on that one.

From the above, "Software and hardware developers may be required..."
Translation: "If your application uses LZW and is a miserable failure, we don't
care, but if it's a success, then we want a cut of the profits."

"tiff6.sea" can be obtained at the usual haunts (sumex, umich, et al.), but it
comes in the most user hostile format possible. It is an ASCII text PostScript
file, weighing in just over a meg, at 1046k (after decompression).

[e-mail]
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Jamie R. McCarthy")
Subject: Ragnemalm's email address
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 5
Date: 3 Aug 92 21:26:52 GMT

Ingemar Ragnemalm's email address is [e-mail].
--
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "I don't think we should have to have them wandering the streets
  frightening women and people."                             - Pat Buchanan










Path: ucivax!gateway
From: [e-mail] (Tom Johnson)
Subject: Re: WaitNextEvent in games
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "[e-mail]" at Aug 2, 92 1:01 am
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 21
Date: 4 Aug 92 00:55:10 GMT

Hi Juri-

It's great to hear that STORM/ASAHI source is going to be available soon.  I'm
really looking forward to taking a look at it.  I'm most impressed with the
sound toolkit you released earlier, and I was planning on using it in
my application.

I think you've hit on the solution: compromise, let the users decide how
friendly to be, and use OSEventAvail for fastest possible speed too.

Now I'm feeling impatient.  How much longer do you think we'll have to wait
to see the source in the Think-C archives?

.
It's the help of people like you that make the internet such a valuable
resource.

Tom

ps, besides, Tempest is my girlfriend's favorite arcade game of all time...
maybe now she won't be dropping so many quarters int the arcades :)










Path: ucivax!gateway
From: [e-mail] ("David A. Denboer")
Subject: EnterMovies and Events
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 22
Date: 4 Aug 92 23:24:23 GMT

I'm looking at ways of enhancing my QuickTime Application, and need a few
pointers.  If a user is playing a movie, and then decides to Suspend the
application, should I call ExitMovies() on a suspend Event, and
EnterMovies() on a resume event (assuming that there is a movie to be played)

Is this possible, or should I forget about it!

Another thing...Should I call ExitMovies() whenever the user opens the About...
during movie play ?  EnterMovies() causes the Sounds (beep etc) to not work
when an app calls EnterMovies()...  So should I call ExitMovies() whenever
there is an event not related to my movie?

So many questions, so little documentation (I would like a QuickTime book NOW)

--

David  A.  den Boer
Musi Computer Products
Macintosh Users Show Intelligence

[e-mail]











Path: ucivax!gateway
From: [e-mail] (AARON BARNETT)
Subject: apple.com (duh)
Message-ID: <[e-mail]>
Content-transfer-encoding: 7BIT
MIME-version: 1.0
Newsgroups: fa.think-c
X-VMS-To: TOE::IN%"[e-mail]"
Lines: 4
Date: 5 Aug 92 00:43:24 GMT
X-Envelope-to: [e-mail]

i have ftp'd to apple before, but lately i get 530 User anonymous unknown.
to that i say "off course im unknown, im anonymous."
what do you think?
aaron










Path: ucivax!gateway
From: [e-mail]
Subject: RE: apple.com (duh)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 4
Date: 5 Aug 92 15:54:02 GMT
X-Vmsmail-To: SMTP%"[e-mail]"

Try ftping to "ftp.apple.com" I don't think that "apple.com" is accepting
anonymous ftps.

Anyone have more info?










Path: ucivax!gateway
From: [e-mail]
Subject: Some Think C things I've been thinking about
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 31
Date: 5 Aug 92 19:17:45 GMT

Threads:
  Would it be a good idea to implement threads as a Class? How would you go
about doing it? Has it already been done? Is it worth the bother? I was
thinking of implementing threads as a class in the following fashion:

1) A CSpindle Class (to spin off threads) to handle CThreads. This Class
contains a list of all CThreads. It's init method will install a CChore
object that calls yield() during idle time (perhaps once every X
ticks).It's dispose method will be responsible for ending all the current
threads and removing the CChore object. It's spin() method will be
responsible for registering Cthreads in it list and forking them.

2) A CThread Class (Does this have to be a direct or indirect class?). The
init method will call newthread() to allocate a thread handle (should this
be private, protected or public data?). It has a custom method to handle
customisation, and a fork method to handle the actual forking and calls its
task method to do the actual work (maybe fork itself should do the actual
work instead of calling). It's dispose method kills the thread and
deallocates the space used.


Hex Map:
  My friend and I would like to do a small hex map based game. How should
we go about constructing the map display? Would it be possible to write a
custom LDef for a Hex Map or to modify the CTable Class to display
Hexagonal Lists?

---
 The Evil Tofu ("I thought I understood the Mac ...")
"No Lah! Sure or not one! Terriblur lah! Kiasu one! Wah Low Eh! Alamak!"











Path: ucivax!gateway
From: [e-mail] ("Jamie R. McCarthy")
Subject: An access quandry
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 34
Date: 5 Aug 92 19:58:51 GMT

What if I try to access a method that's protected in the run-time class,
but public in the compile-time class?

For example, if I have:


class CPublicFoo : public indirect {
    public:
    void    doMethod(void);
} ;

class CProtectedFoo : public CPublicFoo {
    protected:
    void    doMethod(void);
}

void CSomeOtherClass::doPublicMethod(CPublicFoo *theFoo)
{
    theFoo->doMethod();        // this looks good to the compiler
}

void CSomeOtherClass::doProtectedMethod(CProtectedFoo *theFoo)
{
    doPublicMethod(theFoo);        // this is insidious
}


What will happen!?!

I'm guessing a runtime error--method not found--but I dunno...
--
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 The essence of OOP:  "After some hacking, I finally got the program to
 work, but I'm still not sure why."  - David Marcovitz ([e-mail])










Path: ucivax!gateway
From: [e-mail] (AARON BARNETT)
Subject: INITs, cdevs, patches
Message-ID: <[e-mail]>
Content-transfer-encoding: 7BIT
MIME-version: 1.0
Newsgroups: fa.think-c
X-VMS-To: TOE::IN%"[e-mail]"
Lines: 5
Date: 5 Aug 92 22:10:07 GMT
X-Envelope-to: [e-mail]

I want to write an INIT/cdev whatever, the thing i really want to know
is how to patch traps.  I have inside mac I,II,III,V, and think ref but
can't seem to get a lead.  anything that could get me started on system
stuff would be mucho apreiciated.
aaron










Path: ucivax!gateway
From: [e-mail] ("Kam C. Tsang")
Subject: please add me to your list
Message-ID: <9208060326.AA16350@phecda>
Newsgroups: fa.think-c
Lines: 6
Date: 6 Aug 92 03:29:39 GMT

     ----------------------------+-----------------------------
                      Kam Tsang  |  User Interface Group
           [phone] x 275  |  Integrated Systems, Inc.
           [phone] [Fax]  |  3620 Jay Street
                  [e-mail]  |  Santa Clara, CA  95054
     ----------------------------+-----------------------------










Path: ucivax!gateway
From: [e-mail] (Dana S Emery)
Subject: Re: apple.com (duh)
Message-ID: <[e-mail]>
In-Reply-To: Your message <[e-mail]> of 5 Aug
 92 15:54:02 GMT
Content-Type: TEXT/plain; charset=US-ASCII
Newsgroups: fa.think-c
Lines: 14
Date: 6 Aug 92 04:50:44 GMT

Yes, the site name is

        ftp.apple.com

and, of course, you must sign on as anonomous with your *verifyable* mail
address as the password.  Seems Apple is actually verifying the password, which
may trip up people who cant type blindly.

IMHO, any program which offers up 'anonomous' as a default acount ought to be
clever enough to use a non-blinded password typing protocol when a user accepts
the default.

Dana S Emery <[e-mail]>











Path: ucivax!gateway
From: [e-mail] (Jean-Marie Laborde)
Subject: Unwanted events and THINK C Debugger 5.0.2
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 30
Date: 6 Aug 92 12:27:55 GMT

I have encoutered a strange behavior a on midle sized project (1 Meg).

When running under the control of THINK C Debugger very offen after a
FlushEvents(...) [even after FlushEvents(everyEvent,0)!]

EventAvail(mDownMask,&evenement) reports an event even if
there is no mouseDown event at all.

The same happens with WaitNextEvent(....).


It works normally (ie flawless) when turning the debugger off or when
building a standalone application.


I use Think C 5.0.2 & Debugger 5.0.2 on a Quadra 950 but the same
happens on a regular Qudar or a II fx.
I tried to remove all INITs but the strange behavior is still there.

Does have somebody any ideas or how can I fix the problem?
Thank you!



Jean-Marie Laborde          [e-mail]
Laboratoire de Structures Discretes et de Didactique - IMAG
Universite Joseph Fourier - CNRS          BP 53x 38041 Grenoble cedex
FRANCE
(33) 76 51 46 10   (sec 76 51 46 16)      (fax [phone])











Path: ucivax!gateway
From: [e-mail] ("David A. Denboer")
Subject: CDEV, INIT
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 491
Date: 6 Aug 92 18:22:58 GMT


If you don't want the content of the letter just trash it!
It contains sample code for a CDEV, and an INIT, downloaded from UMICH.
The first is in Compact Pro format, the second in a PIT format.

Here we go!


(This file must be converted with BinHex 4.0)
:%f0NCACcDf9XCA4[EM)Z-#jMF(3!8%&$9%033e3!!!!!2!F!!!!!JM`"!6[C!!!
k,98!!)GjK3!'!!!!!!!!!!!!3!#D#QB!H'#(QU!!#(LBUJH'GAQ'UAGRF(CfQ!U
3!!#U"A98Cf@B9P4J99@(T`F*!!L!!!!!!!!!!!!!!!!!!!!!!!!!#L!!!M-d489
QH(Pi#3!*N!#!P`#B!*HB#)N!N!!*!!N!#3!*'L08990P9RD!GRCQKRH)QAKj#)F
*KT!!#3!*#I5E4SUMpFr$qFJ#jF21k[ahB3rr$PphZjH5(AA6ZSMC$r@H'L9Ye&3
*b+ZHf%[$q)di3mY`)iEU,DV)h``h4Ki8Aed`T#@KAEK'lE46(14VTf`mjB`YM'U
'%Z5%[V'kkZU)0Ule*$qYm0mF0dUVmm2pba)h[h5aXU"Z#pCl$I+U[EjZ$U&r#00
HfZQLbcc#`bE0@R[JF2Hr*NdkZqIZkHI42Nb6E0Fq[*-NFkEF0[*$SVSXPil-+l,
`@6G1c9Slp2CUK[SVYKPha[[SmBma`IiaZpmddhTeS+P)`SVrR*0p[[0AK(Hf6J5
p2QFi#'BH9&m1&`1)eIj3`Yahk30AZ66m26j5mJZlF60l`1&6h#k9N!$YSYMBKj6
`dp$b9MNQK@+fN!#iRaEKc3R)(lSdbZU)Zir6[&E$()A',3fbZK,'j"95P%0rY4C
L)pkT@q)9b(REB'U8HAi5ZM$aXPi8@AmN,ife"JR0Zp%(9CimbU3pZ&fEQKBY%LJ
hE)m)b44BGk1dB!9'@"JkH[YkTqZI9hmj90&@0(CUepiVeME9,S&RrK$h'KZN5jf
!8#k%pDCEa2fSPr06MJK6bqeSUdBi2-T'2DLVPB9!9GL[K4IK&4Cq3,$+qd#Vc5e
ND,P&IpPPHJK9e,'lDpf0Y(KB+CI'8J9fqr*0(r`R,E4B!YSRe4mLa"jPiaYNZ6d
pRfqrlNPHhZl0%r4XlTd*XqQf[!&IaRr66U%S,m+--EiFh`A9A,VRkZR-#+BLTcb
AQReG$d6IbV`KPFmJ54#P8lRQLb9m@j-G&Gr#9rb20A+S(164*0h4QcKd8B0Seh,
qHR#[k[Jak)d2fCk4!$f,IeMj`bMNESh8AFd"Yqpk%G%Y'qTm)&Uab)"HLZAIIim
Kjr-CV26N9KrERlJ$6$3h'`CZ0$6'(SjpFm!KiGR549@9Mb[FA06e+Z200ZF#`X%
GJBHb&Jb2,9SlPM)FB2X+'AfpTMpZ0MDE5PJjbm+K@4JcX-3-E0JX'Qm!jTUNEl"
jbm*T[T(cRqVFY94Kp[[aDHQ(aV`jlDXTl!jcpSkih$9HNkVCSIRrL(YKhr+Fc(M
!RP+Vq9d0dU)$8$HL98HZLrkCXfBe*2e#L`9,NV*,dBi5*mY*eH"Eh83L!3LH%48
!6D9FrJ(*8`pNP#`f,396AjBX!iaGHY5KJYC%S+[9KCL3!(Q-pJJ$ZqHRA1B`3QP
m9fV*kSrck5G)pZc&a-*cS%UC!Z1V0UCH,B3+'Mec+50(M3-jP["BNiAi,9cfIRB
T+&[#FPIJ35IK`qHTK6RaDhcp6p&P30C8qp"G*!d-Y6IJ3l86ADX@rUa"10lMj8D
mTXqS(%MDZ"5+U*Zh4fK('h!%'*Ah8kHK6ZdRLN[03K8dXq8[BHRikiIdrleMq!p
jG`ahB!RfihlM#GAX(`Sb)1U9&6#YU6+NU4c)IeBNS%flEC2T`imF0qYr1'q0rH'
r@rA$I%rh$I%rr$Dq'hfiDIAh",Sk*-pKrj0Vbibf[G(I(Ii4ZjrlN@DiiE1#"EV
JFR4pIV&m"6@N[XPI4Jhm9b8T,P9qp4[0-@mK%EACVe185VmP0EeF644aXPd5E9p
`RN1f0Tk*C42aIrilBaqK#'ErQIbV'QRNS(r8!`kbM!hNJZakGCH)BaTeY19J%A4
GR2I+diJDQA-h%AkfX0eG[R1kE2aBqF5ZR6p2Ge%2aX96CHV*KH@LI-,)40qU#&e
IAeV0p(G%hFR2F!fF!!"#!!#!!!8'"J!!!!!!!!!!!%!!!!"i!(#!!)!(!!"S#3!
'G99jKBQ(CQ"QC`N)!!#3!!9f9(CeQ%G8F&9@H3HC#3!*N!!0!!)d494'CQ969h"
i#!NM0%48499hCQ$`f@FB8dh4pV--r,kDG0QcMA[lYG0HR64iF+q'QLMEirb`1kD
12ih9J6bcpj4qpq@Hq2+(k3hedlGp@QMr[rq'IR(KRMIKce3bcaqICfI4![j6`ce
3[`cMcMLN6b[rZ,3Rj@mJ*m#6V!M618mG8*6`jJU5+q*LY&&HbSJK6BhCiKXI`lG
!J#LLNJd$@hYqeG2(UiL()mXrL"Y,m)Ie3)'qYZ&c,(N"$plm,TreUJN)#J@0K1J
e)'5+A@jfpXqQ&f6X@jF%4MZQU#3X0j*0j)NVFXkBbPUJ3-STlK32A!UHFRIcYbi
FXCbPffL9qfFj4Y`+,`1EYqfQZV`he`X4(I9*ThD$K63@VHZ$QS0'l'I+bTS98[P
,[iTDkehhBaBSUIY(('qjJ1@4%h2$e%mQ0F)b$V+6)G3MpFYQTYGeh'DBP6`BYPP
`0p+L++KUK"B35A-&jDCR[Mk"qGf-r3L*)phH'bRMCYf3!2eMQm5$TbLm@FV8Ae-
1D2Y%[beC!i@NmEJAXkrSrcI(2TMKP#kI6aP'(+9r,m`RM$#HIqUlSVa0(SUZY&j
BA#[A9#Uqf8qDQ0M(bfG24VB@1@*fbMK9QF@bc,1h2S1Y22&(),Fi"KH`@V&2VH*
([GU3!1ZDC6b2&Al+pI,1rfI"LU0Vq'V&HaV&2fMlTXAc,qGb!-E8UR6kA2mS9G(
I(,+hR'(9kCFqZ$f*h9!0aL9Nr,G-I$J*455&3J+HjFFf)1l%B9eA0hhSa1qG'-F
Mp4*dLi&k4EVdI@QZZKfj62epfa6F0TR@0)lJ5lCkPChl[[Ahel11XU'dk3,I)!!
!!)"&GQD(HB#(N!!*#JLJN!#CN!!)5(L!!(N*LATiS!!!PjN!!)GeH)LAHAGhLAH
3!*N)LU#3!*9eCAGQLAK9L@CRL(L3!*!!Q(LRJ)#!S*!!!*!!N!#3!*!!!)#CN!!
!H(!!QSU3!!#3!!#3!*!!!)J*#3!)!!N!!!!!J!!!!!!!!+!+Q3#3!*!!#3P`F!!
*!!S+!)BB!!%N49B(GJ"`!!!!!!!!!!!!!!!!!!"`#"0%49C8F!"`K#3#9p#%+`%
Krl'NcT2&#[)&qarLaj[cF+@e06V84bG1A-c)3`TE0(8dY25PS`"Gl(,cqGPkI,b
4A`R`CjHl[qYf34`,(0XfldEGkMT#hqF1G#Q(HNl6)hK9rXNii@iE#hL4CbD9mi$
9q($0KCKmXPTiBVEc6!,XbHfKM5rlZPkmRmT1HkB`H*!!j%2-KpX2bE,pr(i1K4e
BjGZEAUePH9qqeAI[hr(Y&rH$`GhEh1rZ9["r[Ze[mpl%VGr[HTYS``jp%Dfjki%
jk%FUYi2RfQ'%%r#rIrqk-G%E[rIcm1lj@*,Zm8#C1*,pABa*IMrMp[#qT,j2ZZ"
H"i`,XpFSFTEcXr0PPA91CTF[Q+S0q1C,SFCSS-B-jcpFDVe[kif1%FGAAAK"3Q%
QmXMXB#+9Q'@&ep%KpMS`l%2KKppI"dUV1Y4FiY,9eH(%Kh1hLVjV6pfMAS[98aa
G(8k0%pk21QZccDrRiIXdA,YX-+E$AM$AN`r(YmD@VTpDjEeV9k2qSmR)p,)p()j
2)MRfjl8e'['@UQj0C9Aj!`p`BHmpNYZl(2ST[%BkXebM'MQDXHY9X4f,Y"l6N4[
@U+Bp2ASQ#&fp0HS4+1V-8[4E"Gb0ZP-ENCY5VB[4e+YQ09b0QUIBk4&jP'FCChZ
3!&LGMb)DX-5'mrh9CKqX0Q6Mel'5T)V-a5$rfN`HhkZ6'kb#c-ZUpFUeb#dPmCG
(8YcPL8aHac'`m2+khT[-HcFCh)B3i-*$`(Y3r56+I[k-*HcpH$d&jb(r)B@ARD2
0"QEPjRXC`TpRT66fJK5cdd)HrPD'AR!MY-d#%2NFe$kE-pl8"(HTZ6hJ4pfqHpL
XFPl2ppq0qr''"h'E0MVm4*mcGbCq8FhjJcd)5lI`0B5Id"Ra1$0'%ZdU)@fp!'E
4)1'$04ej'&EP"MiQm(mR4kY*hqj4G1r6d0+J!!#!4'CSCRGhD)PSQ(QDGkU*PfL
,QBPkLTPfHT!!QjYiLTL(ChKhL'L)HAGjD(L!P`#DTiHBKiPhQ@KRHRGiLEU3!*!
!URL,YhQJN!#JQi#CN!#UX*QUZUZUN!#EQ,UCUSZEN!!!QB#!USQlQlUTS,#JLTX
+UjZ3!*!!QD#EN!!(J+"`Ki#,U`UCN!#EKK-!!54&9RH)Q)Q3!)N*!+!!!!!!#Kd
L4&9@9QC@ChG`L)!!#(L(LBQ!#AH)N!#3!!N!N!!)N!#%)J*mlB3Kmd")k-qVPCd
rLCA'Um2jP2(cFVMCR#ajr%bDQ1k-DcFF2(iqqm,(UBqGP9CrVBmJ2X1ql[#[GpI
AF14bCEf'@IRG2Hq1K6Ari#$`i3XIf3a*QlUjZGM9FkCJprQiqCamIA1#%r'Um1H
i+@'rUjf6R"R2NephamE*UBhIe-Hc[mV'iFqVMq(2i@99cXHVRCT"qC2Nh9GpAMC
1GRC0A`*R#UC@D"&JL(*UmB#krIBh(ajmQIMCT%mT3C*R`P`QJCAS%ehf8+9pp`X
M+RlNL8$ZjV9Uj6*6he2F9+P[QCZC`J@qM1KR`NP,14bCLR15a3K$9-$+q%ZpTm#
Q,()j-pJ9b16XH%)[6RcAa6!&qZLUijphKB9rGFMNbNSf(U4m50R)cSA-I%Kpd#0
R(b)cC(L!h0[GcZlqpl["i!'5T8)q$#!E9b$X%"G8Q6ZpjZ0a'X"eGABH2Qjdqpa
q28U!IekKL4#9%+!2lH6R`Kp,mrSJAmhBiG,Gi'paF+lhfiZlrEBG2IhhdYAI9-I
LjYcFr4F$`Rc`%hZih'$HUNL$Dq9$V&4HRaLX(&alHrbHr"DGJhQmRS)M(c[m[6m
pCFqcl)$E#369D)meHl,BjR%aZ&Mfp4KReVfCiPAG[4R*)aY'9QP9q$hrJKaa,I,
8QBGphZ(#jKh%INNID8eaMq(rlp(F`F*%PrThL3DiXGD'83Jf1i9HhL(C2iKqGre
Hrp`H%`+DaU,AQ5YT#BN@CZ,r*cFjL$C[a"`[li-)P+V6fB`p9FT@V[FR'UCAJEr
1bDQEEjB"JVeMqShr-(XV@A$8b@a-NYJP44EjE-b'*@YIL9hRl@bMNBl,LDcfGkN
KD9@K9YP&X3i+Y6(qSYqkbdS2#CkSXYDl4Q`XcXhrjJ5d@@XU%UMrk(Gr+l['bDY
GJ,8ZGE!,Ul$XmAIBp6#c-VK+Fp@K5A5fY'&,DdMQ94QpRLphMjf4KVKlQeZ4bE'
%LY@A1el1!AeES[1ZPYdlSiCdr2a,R1bVZpCQI,ePdqp"E"EP+dedTSRlj8c++B5
eTM#@P1EG2G,VSfPVPiAXhhCGl@h9lGhY4PYXR1bFFbLi@5'pN!"+bi0GG1hrKC`
h@Al$[Kk%#Sj+X,TjV,j%2ANI@KXi5BeT(hJJCDdJ"ke%-KE(c&Ak,,T5b$+[mrU
`Ul4!RY`UlEe9a5im1E$M`q)"2MKairL!6cJ%q!"2r)H($e3%pB"2M!6j)H((m)#
IL!3()r$$3#$3#$3#$3#$3#$3#$3#$3#$4"c4'$4'$4#64"c4'$4'$4#6aJFmB(2
'"6aJ8Eb$eZ`fr`arSMFrBV3a)IbKm8EQ1d!c`(X-b!eq0`Nb8&IBV!8C*Ul'`fr
h9Q4C3Kl2P`X&4H4)NIJ"lBEI)FBq0X0YP`f'fU6mAm(mf"k@UpbeQB(0qAdlrhj
fIJI8Ri[IB1"d-$JGAq&,5NehDfm0C[m%(Zql'e#VfVcY1AjZ*Jd,H&KG@m+ld,@
faEAZS4jIQcj[JDqK0T9B9`#@&+VeG2PqK3Qm[dU%e-R"PAP[eG2HD2%PhR&pf4`
E1K,G3Q&AiprJm[m[dXAhC$b$0N3Cce"Q$U3X'3GdD%em`"0$k`8!2(SGUh4&$ST
kFA1Mbq@kZ0LK-9YLTD`Qc0TN4%EEMTGATjGeXIElcp0EjAbdD`5TVM40BX$CeHQ
rjB)bP*D)-dS@Hbm8h!`VEIF'A2`lE)K1RiGaE3XZB1A%kAEAm,#rpqcJME$C"eC
b$VDP1XU@IYU-*U9,Ilq"aRJjB@e+cr*#[Df0Y9@pfPT6,R%`91Q"cDfMf@,2TM0
CdZId2*YU1f`kh[AQji1eZ*HP4hAmB50Vp#%ZPrYlRfYYi8*9EhEcGF(VjppF62A
q8PM,K+bjG#(SBY2GC-[me@YlZ9m02Fj-[R9Dh[CA2[rIerlhU+S3S6EBLVDH,#1
TdVcdG6Tr2U`QkRmAa9b%#J9bLEXJFhP68k@9f9afZTdY+M,SkR4)-K2eh3r(#9c
2*iNhX[+3!0EkMY+1TdKUC44U0@k4,eQNBd-Ql1hK1[,H&PpH2"N8peF60+Mfmc5
ZdS6qiK#AGkQRd28R3jZI8q"$MV4cI+iP1Ip#%VPD2D8B5Yi1Q9B$jSl,2i-)IVZ
*P1LdXTCd)1R$!`K6PEV5SdZI3KJHP(Q[85"apZIUZKSl(AHdT#j(%eMd`!jiNfT
)KUG,`11M+Q`bI+`r6NqQDIUZ9j55%`G[-ThC-&hUG(jqI1HMM68hFV4j3q2#,64
&f"C#&NCV-YBD'6@jX(!aPLYP9K195'P'f,+9Y-UCXhBH[LPh1raK+Uf@bmRIi0$
A'p8h!j[9m6X-@&P`GBjGM6bZJV#&U(Gj'XaVP*VNcAQLaDk)Y6R&V6phe)3F31M
PI`S5m[KUESHiZ"QAD0$*pVc2[r6jpl$X+-*c[%*YaY6QdY+eZHj0BPc1rPq[X-A
8rh0FT*aXqfEZBHc0QZfb)9fTql,PGY4e2e+B06p#jA8,I8rG3eQ"cIrlpQhL`Yj
IC8GY6e1HB@K'DX-AI8K)lDPUFkI9e1GFfaL$f2EmG"Qfb)5Y6QQ*)3pZIHYa0ZZ
R#'r`D4MjQ,2TcVAI(Nj$e&F#4R`2)H6TZH-k"(3Km"P@91KUXrm8Cf*FRUL[aE0
JHRUq9*G`JTqq[G4G*jb'`1X@&b,Beb#ZXIA8K'hHB9rH0lBrImViep#@DlBE&I`
[A2lhMXBjrqGM(DRc(QBfBHVC$1H!QG#1Ir9'1*FaR3VSh"qhZqK'2e)4N@8*%Mq
N"#pXMiS4NpI#9*ZB9ak6@eGH`[DlrL(PeqI$!VrFKipK8K0X2kiF1`di6V(C`P@
0q!Q(#EBqH"(j)5l(r3"1R$@+'IQC$NZbU@P4jr8l6pmLIP3Rl(+KVk'8HbXrBpe
4fjbpYS5U%lHIFm(XEhmTmBIFm(VE`#,IR86cfSGdZKR"PehV`YD%HTDdXrUDh)c
qTDp#MIqr*NBApQ"aU@Pqp,8N@Zi&Ui&VYBGae*e+(8mBhrlhU([X!Rph8lV[I3K
YbJAqXf1eH8aGSfIk-r1NCHUQ5T%P`8m2Yhhri)EccELZpS%pI(M`kc#TA[HJCbG
c5[DB%H4ZH"Jhi%HCZGpIES#22i$3MdpchY2FJ4qBrTYm+2kYa6[Vm#2J`UHj5"m
Qj`%N4PplHh`84kfpZm1l!MXEe&%)l2!aZ,MJ4h0+lhbl1AQji&m1%F#%+bpU+k'
piAX3LJb6fS''lD$1ZV`-jM3bCb!-p"`-rB"RR0$,6X!-p&[fc[H%A"AfR-a!9,e
X,FB$2&AH8$-F$-Ka&Z!-p9`-b3-rYF$1+"Kl[X$2UJBIVeJCaJ-U0$+rVJ-*a3C
VE3$1qF*2V!C`fBZHrU8!!&8!!*N!"3!'!!!!!!!!!!#3!%!!!!"S#@GJGR!(N!!
)D+LJPhCPD(@3!'KAF'CRQ3!!!(!&Pf4hC3P'9A"99hH)Q!J!"i!!!!!!!!!"!!!
!!!!!!!!!#J!+)!!#-c4&9@CR"iKiL!K`!)J!!'!!#!"iJ)!!!!!!!!!(%L-d489
QG@9QKiKi!(B!KRH!"rY0SeehiCI,liJ&fqAeZVmH'%2r`cHrhjXN2RAhm+SbKr'
@'LfbkVH#FLV9EG$c[M$eV`i3`i4KTVUPEipZ&FViHGPH'@(99C[P'q%JRlm[haB
XAE64ZJD[q',&46ZRfDZM42La6GZfIELQQdD0mI5Lc$`)IqICVRqFp1lSh8GG1,&
pZ6fr(kIq)&#+Ql0RASRdpZbG%IPS)'KMPXMhiCi%$I$&0lILEec`rUZcIEkpQ&b
#AKECKNKIArXFm+l-)q-9$2CGEhdDA39i9AlHqkf8Xm1Qff8DV2F"QEqHMB!DDjD
Va6G-rbST!S8@N!#N-raJE1)[)94MN!#rU3Q*ce"P%)%dP#Hd0FK-Qq3Q`[qQUiK
KJ3*Cc'*X+@M8b2`hG8j-kDl+Pc`8V#q5'ER-rfa0eBpp@&A6EjfElmN18!H5![a
bR&(H64bm("rGPP(`0CS2qK$r+D6h4qQ"3[M9$jS8K8LNK8JJ#U4FGD!medapFGf
5$CNQQmN%TA)HSL@#b3hAHB'Y98Ve!i"fddQY4*be&rcrX+D0E%TUUVfr(j+)HlZ
bhaPUP9ihRC(VXPpHZb-2eK+QfQZA9A+[!U2"RVdfkEU[A'M%8J6@-dp1N!!3B-q
qeZUk*)pHQEZkpHQZrbY[1HQ&646e6l+0dqQ#N3j@C![Ej#d*kVZrEpc1lYH93Zk
hR+FdA'0QiIGPp+lpRMBfX#C@Q%9C#4,0X,&X+M2p[aqEj`dCYCHV$SeAj"JrNc+
FfUkVM&"Tre[YM)('L)bq85%%ji%$%L9f"eM+b&,1NK%MI5ebVZMI[h@Tq,&C(!9
D!AQjqGXVR0AYF#$H9N52II@&2XYpFBQ2Qj4addj5VX3D6papPTH&VXGYfr(qk-r
h$D$0lKZe'ca`i+FJ%&EmZL*2E9k$EaEm1SJM52U8j6)*c`[`qXM4iZSmbdrCD1R
cP`T3*Q*bVEi,EMfNaiM(C(MEk4eA@m8rXRQ(0HQ-P3M+UmlXCI4q0h9fdk#p%UE
RbMJhSeVBh2"1V&pjL8-E'h6%dhPKFBT+fca!`BSaG04r0G'rcN2CbBhI(h0m@mJ
6r5[$'dh'HDif&*I0crXVUShd")FpKBD"lDZ2pQLRZ%+,M(M2GF2NraKCD!TkfPe
K9RS)aS'L$Hr'`-8MJP`K5JX-c"L,mH)L8+P'lDeb(K"EqV,5VZE(dMB,+cN$ME3
F*#XPI('UfhfqIpbMSPAhrid2Xd'T(KR(k#1e$cjpG[2V6(2G8`T)%bq[#0`bmJE
aYheq&FEKrpZ,CVaBCrV)00"Z#9Q$QPLqV3!6bJ!!3J!!N!!!"J!'!!!!!!!"!!!
!13!!#@F!H(#)S)!!U@J(!*CeCAH&QBG@B'GRQ!Q3!!!!"ACNKf@D9e9J99Cf#3F
+!!L!%`!#)d4&9@B(B'!!F!!!F!!!#)!()M46998(G[DEqVZ9mfqAVeFIrjIB!HL
-+[6MC+0`&Bh@9BBG5KUR9YRcaYi9i4GjIj,GM('V$G9BSUjef@4GECrXFlVrr!2
ai4YqG&2m4V86I(UprjK'dh4EGM&@1-[6MM'0dFX*4AM&GX5U[XVPI(V+r#Zkh!Q
!!dFdC3%B5aMPa*a`UYhL8+KQ%9B4cN))!MZXZmJjHY9jRQAaTSf`eP2bbjD+GXq
cYd66jFZ6am*r$,Nb6,'mQhqYFj%'&mGFDZcpjjYZC#2S"(l8@iBe@lT&LVUmV*B
"QbHfS6Lq[I+f2YbYhBR!ZQ2+8BFVa6kK(+lH%VkmCEijm!6fbh5``U[rdRrhr(j
DpQUDI6il*iSYVaq5#Pbe93Ff4I-Dcc",p-i9XCHFVqKiBL*R"SQZYa[ZX'bEC@I
S+(aPZVqeHk25@2#lHNpGVQQl4jAFM!FQ5HR58UE96iE3)9%Cl1@10eSder`ND#G
'N!!Il[MlrMrdLHqZUblcG#QA*fq0-ffM96'cPDGDCil,VV*9@JaD(+CFcCXm-fK
4hkrT2hcdlG")-ZAfphhr(pQB[bIf6pe&)JkaZ-rA'frND'V$RU+mH-Q6qG'`jrL
2H,'R2!Y-9XZHCK'GJC&T*Ff$$ehEY6IhkqC-@D+IR2XSfck@G,Ib'qp6BT6D2#F
I85p)eGTaTcK@H%k#kj[UfL!I@M`(m`$4%dJ,rJlL1ZLlmmD8kPVa[4HGb9",MRM
Z[Uqb%,FdlTBklVmFh%B5I,QVc5"[H,3T6c-pCda64p1Q2VAE[ZjK)cHliG(6(R+
fAV9daqUN,C2VRd(m4NllYp9Ld2pY0RRfef"Ak8e%R#['RE4p&Dakiq#(fQ[$MGJ
ai3Qm(*%qDG!Ge!!!93!!LCL'N!!'!!!!!!#3!+!!S%S!J!GAU'GJKhLDZVPjQ)#
RCQ9SGU"hGf"f9TLV!!"`"ACNCf@A9e9J99ChL*J*!!Q3!!!!!!!!!!!!!!!"!!!
!!!!+!!XJ!!)d4%499QChCRGhH)QBL)HCLBQC#3UDUTQJS!ZJX!Br-d9%9QC@GfC
hGfH'GhL(KiU(LAH*LCQ)HCL*G`LTL)L!#CHTKiQ*U)U+UTQB#DLEX*UUZ3QEUJU
CLBQJ#`QkqYl*426AhkEU+EF1lplre[BkphdXSlpYd2riFIirMai)G0'VE2'Q(qm
--GG9NqX#FK9cceDkBf`RKhEkY@f&Hb'Xa1KEG[fE-2lhlqRUc63A-IjAlqEUQPl
-[0MP[hlfR4,S[hVf2SSYZ!E[6IrCj3%$NE0G(al)kSHq(C,Mkqc*I[Iar2Sfcfc
4qGh,$&AA6'HVmNKBL'`&VekAUb%9-IAeD*J%,J0qQHc[SU"5j#$AkFhBSfc5mX*
T6Z5r)$hk`1$)E+l)AEB`Ye@9ddd9Gm#*-*+0N!#HVkF-2hA)B5i))3'13b"6X39
K`G1MU)6MIV#B#miFi,B8J-14[*AlH9!S3YK1i1%G"MGLRX"DVUZ!03ja3Lb9lqk
Q11QM9i,V`!q%TM'V&A[UeJ`'FGI[r8m3X0iL'SZSMD%*bkHV(0QkqU(aMGNarT2
6[M#6AbSL`ch@'HlHS#1FX++VSpmE1&3+!GcpRAMPbDHb@'JL&G5lMmi6mL0Da6C
%VR*))j!!P4ENj+-8pj5C2U64&8H%'LkcNrarJLFb@Gp5D&R13@5(69prH(j[QY$
0`f1)#eL)JR)GJ*XR$EDl2f`3mSf,98f6LMP(UMjT+ML3!,ASZVXRl`c#aQUbf#"
IAXjBI+LVAAjU$@`"I"#fMpPhMXdP8HJ`1@LN(ebF3*dB!Kbq34m3iVXeV"JPIjk
!j"B`V9V9&qD0T2NGQMG"mbM[dlY0XE(K*qd@IH"CRXVe"C`"J*fEqFYNrLq%TM+
+pT*1D[i`pJ*QHFaN+N9ZAdJNf(q1kbRR&GKl$p`X%,1R#AkGfZHjT@rD+C62EY5
TQjhPr[rA4ZMU!NF,A*l2`XIV&[094FHM%#Cie*pj(e`R`"6cC(@VaNSYh9faH4E
Dem$h$69TQTH@FZDf`kZ014#Z*!fVh)$%(QT%l%#dch'NNml"a#eR8f'UmXiAVL0
d399rITcp%[6,e6Fa'TN,4&reEkDCI*cJ-cR4*EaH5mjbRF[rALrMqBIp)#Ml,(a
2pj&qfpZ'"$GbFX2MC2X-Blpl&,mFh8!i*6mpGPdQlM*C`+q5(,ldLQ3@E5!j@*D
pNKJX"E`m*)MHkpdDMMcN-%',`C%AGbGZ(F""LSZY`paJZBaik4'q`16aj%DFpC-
cB3C1KiME@4p'"eQS$%c25,rI2%X3l%3ZEUk-h8ADLpIZPaIqi)H[fiZEQ)NIprM
qHLm-5J"(p82"JD2rXV&r+SBT5$5"%3U[ReCM#5[Zr8UiAM[!-lS`h6ffae`ZV'$
HLf&Kb&rBYAYpi6+HVQb`-'iIRm)G@ESK0cbN&epEXQJ-)eX$CYC[#MA9)36@EbV
j)A9Ge[h`9-kPfl$X[[BGNZRh0Vr81Y40*Y42#el9TSNd5FedkcLGKk&kp9(cF3Z
XllRk+pAK)FQb*lFb)d2PQQjd9J*THhYKNkb+#"d1f1SiNS2P4(c,3r`h9lSF80B
dCdJmrH#8K"TG#TCT0L4C1IiBIh&IHU*j'53B$UD8iJNpZ##adiS++@"56'9!laJ
jc68l1HFjAPk*G9P,ZhLX*qHFX!bqK!Pk@Z00dl0j`F!Cfc-,H0IP(T&J*cI(MjY
%TE8"'H(AP)B89DGf,IGGA9b`-XCM86-mA'BSd9C+r1Td%IX5)mie[Y)dD$"pT&D
-,L)N64Erar2f+)%KiSZkX&haiBC-hk,[cKl)-&mN'IS`R,B-J06LBH*"Kka06fI
,0S&Hd&iJQM)H8k42i-Z!R9p[#UG4P$`rI2I'"TiFTHk3!+e$If#@)*HF4!iU%[`
36qQIjY*@MS+(8X&&e&V8XIQN9d92`@(!@SUT#QTcGPJ8F%LTD`3iT#QV3p+TF8B
130RhXPqCYRim@)45Ijc9L&$DSimj&@)X@#Qlb5SLj-H#&YA3E3`iS-%CML$0*SJ
BIRlh560BRqdjJ2ZNS89SmK'9SaK+9[S+@J@8h`'IY9I'E4G($kJmdN`5dMjd02A
Ar9%*Yj8H1&Kq"AV@Gi%a)DVDS8c5Xp0N5d+%hfl85emIC'f[ICUM*`65rmQi-"Y
NR0N29)qd%hDi%EdU)hU&b#*jBpSN#"21R'JB5C0[#cZ1Q&q1FeYjDiNF-bf6fa+
6e3ClHh#Q#+"*QU(%Dp")a-mdc@)L(1*9"C`%b"'[0ijL(dRR!$*)dXAdR4ElCEV
(F3EAmcT"-rK@D%GD3YB2P'+BhTZHXFYb)iNrD0*V`(&KMkNl'a4,M8e8PbK5V&8
8TP9X6$ie3BJ5H6Fr1'`$$'a8Tj%58E9V3ETM"F21qUNiqm36J9RGTR8@Q84-QB-
c5mfUkMb(LhC3VHF8$lEUDAN65S'6)b1brCCkE6FmCaUFT5'm1TdACGhhqJj*"-B
-KEjGha[aDVG(U)*8AI6Fd`cd@-i48ECaJHDfCLmN"1k*pK'mJ-#D!1"L!-4(-XV
#9KA@5&b%,AYN*I[0#hG)rTdLNL$T$"PhJ+r233P&%HQ4C%arT54EeGT$(#2BrlA
KM'ErQDmQF-aJ!U*+QE@XfF3HJZA"`)BGlYJ@U8B0KddGG"VB(#&+DKB8AN5K-91
2C3YUjNr)eFXjE@3jlkMlIeR0f"IQ$VrPYB%PYdlBG*!!Xl01&XBDG#P2NdMIfJ-
VflGT(pY*U&Qj'R9Ufq"@I'Dk,L!I%Cj#$ZZU1)%XJclVMDdB-Ea+5qNr,r2IDhC
9,+S2D-G$GU(iDKHIpG"'0jeXbMhV*[rrcbhCC[#YrV"XE36p3*@Ac2AD1S+ZT1%
3UdKP''hJ3*9D%GHmX0q49mQFJ8'l1%c[%''FY#lah8MAN@[c!-8af&X-1ZrZZ0N
4b+b!S5-eP"'`1Np%+d!Z4FKGTK+B2*&ADE[3NJKZ#YMefiE%FBdPLJACK)9m*q%
BIjb0TNqr5c(5Z()$Y3-X,SL3!$[h*i5b(jXf+hVP%8rq943),lL)6%"+-!3T"IX
JCaL8U-l!`+)5V"*#+Q(+!Cl$)BK*cLC"p-%&fHl6$KkfA'rdBIVk-*J@24D04TN
(&T%'FY%R"Nk1[iMK&S0MB31d0LT1`R3i'd*D"BP*%lLC[e,11cq4NVcf8#13!*0
6lN!#4Z'BR!SmRff[c1k4N!$aklCcVrYC!J,dLY'i,1UB`2PN3Icm2%YME2j'ph+
r`+,TU(k*#*S[GfHM*&"MPDCAV(Z10E([XY'ji!-jifc0kP!Q6dMT)5$NSNF2RYM
BBbI'Q[Z'CLX"UHQ3!)3REZJc%KkDU3c"`r$BR3dKm2I$MF[2UbTlGUH$jm'fZ5f
cjQGdR5C!,VXNSa4Rm6Ja'I%VB#!i3)l6@BcjU$'ir-H!L@BdiUEFeV!GAB*KPhH
2YfqZccMQ-V@##VIlm41!(iSMak(2+3QBSY[Z,3LNBq!&AEKRb4f+mDqH04TRIGJ
KlMkEbXf+%Ji[`)#'$Q@bIaL1*fV@`)H2r`J)b*`rYj(dqIIS-0GECmEjSme)H2[
AH2Pj0rd&#R!8XqI6d(6KMR39aN-G,MPAJDpG1%J+FeQ(15bG0&TkZmY@YQpKqT&
-Y-pZe2Ip'SmpH"aA0$4Um"R8RZe$e-dee"AN9bhp9rh,%aZHQ*PmmEK[VVHb4TR
qNR'2P8ZQ,l%-hSFH9lm6*CD+4E+FU6!Y8'G+#`B*ch23[mTq@'+ZZQ-p5l5DYZ1
[@dBa(m%P"EaBa'J0lJ6eVC3&+(+Z2+Sbc4DGh0q"j(P1-Ck04GGj8X6TklUMAIc
I0mdZLfLN9B0&lQp1MSV!A3+&TJNe#Vfmd2Q`Mq`U39-K*($iaYY'SbAPXeV8NrD
UK-p4*JZH0HqeMVa@,QieMYDlB!QcZhENA"b3!'H0G3(p48p,8UHPd+RT6mbdD3k
B"EK%S&r@IZJAPXIU#K1qDG*k8-p6(C12[BUQflr(Z@@YDJ(lLMl2kqjpAJ[lr8!
["!N-(lZR3,lQIadC)ppc+28r8@4X4T-qSY(Z$#-Lq`YpEAr)lrSBb6ImdGd(2I"
9qc6bYH-SN3+XpfDSe*KRZ,D#p)!TU9eQp81'Q$K%D*dR45hNVhMMjadL`LYG+-@
FPC!!(N5,h9baLe0@FdXc&kR&f5e4$`Mp(1SFH[-4Ma8AFe@YDVEJ'p92B3HkClI
"DSR)JCM$*lMliUJL!KcG@5%NdE5jqNHMlM'4&XdD+"52CHkJ"*DkFRKF!J48*G&
1*e*m*LC+e)CbIjFd0j(G$5hFhrN0D0YeJepRbc(ei23E6e3'a[aMEYL9VjlCC1D
Q)UJ0FX'`b$jl$Bb!"LedA,c$#U'BKmX$!HB[E+Dh6jdDlYZ#'dhLfFq*p`bRmh4
f&rDL-Tl#2K66!Nf8eC'MfdmSi2%Kjh[0,2dFmp6cdZ@qU)lpq&fcXUr%4ecX[lc
mVU-kHp!IqZe%&U6i$brqYkmZ9lF`ZRGTYMBm1RCT*-,aE554Zelq'[,m0'SQ3T!
!P'aKa8-RTh0#fCAMeBZIF`GI#brHrChf6r3-22F+MSKUr13alVKmXdh1F(`bGCY
hX3`9baQj6MEm"3(6jp6FRj`ZQKjHh+@@LV@K0C!!R"i)D2TD!L9h,-%10lV!+KN
C!@-)fQ&*EFF@5S#lUVXmCaB,IM`IY2k82fA,d00HaVA-2"1Mr&MfHPraq#fLUmZ
(Lq8U[b#Aj2P6q%-rHE@M90A,mk,MGETd3@IHK)#[e6FiQ`lMG(b%JE1H!6`J!!#
!4PGhH(PhD)TiLBU3!(ZULSGBHCU!HCQ*GhP`F!#BLRQ)GhGhGfH*H&GkKQLBQ,Z
DPfH)KRH(QAKhLBKiUTQELkU)UE#UJ*!!QUZ+R+#X#lUEQSUCN!!+CjU,X+#VN!!
,UhUDLhQ*LUbCR)ZBHlU+R)UULjQ-Lj!!L)#DF)Z,S*[-QTU3!)BB!!%c4&GhCTH
*Gi!!N!!!!!!!!!!!!!!!N!!R*#4@9QCACQGRG`Q)H)GjF*QJU!L*L!!*#CN*#3#
U#CQCQBN+J!!+K#8!QTmZ%1c!59Vi3U0MTYTLlV)bXc&bI%M`-V-aSF6kZPUTe$J
CNGj3qM`)J[h@lSI4fQcZl[@3!)E1'`##THa+'rld&Y0k2rcDr83Hq6qG)%i[c3l
U0M9cFc&hppNj'2[-`&UlqYJYmZG-`*1qM`mAJEV&bBilDbY)pYQC'6NCQ43i#3(
&T'&(D1bK#HmSEh,8MqR$3K84C)6a`dmA#PIELc*AQb[4PHM+j%VN5[6PHR+p59k
NVPbZA+jNVQ5ZG+jdVS5ZK&,LPaDQ,8b[HPHp+dC@M+q#9m%VijAaa8m928AGhHA
[IbD-Vbd"*1$&Zb(Si8dA#LlD,-Led9Y&EGPGlM#ffe3SK$j(j*pJbM[AM44PH9#
&hGi9i"P22,T3%`lRiUAl1fUYCkrCHe2KTIrdcUG(2MbiDQfVBpK5rC8Ci2Fk2Km
lb+AVbCdV8E2aS[Xq*&aphaqh!l9bCd2'`IGTY*Z2r1clb9h@2&QdT1$EE#PjdGR
#RakZ1iPiFRm-H`Ni0R8N$ICeeEGFDI9l+)0Y9E9qeZZPpQKqr'q(A9mR"jdm)-U
1YU1((``Hj((lJ"Xqfdmr8@(E`Tr-iYVkYVmFR)YIMKUVAPI2pHPSckkflH&62de
VTjQqVB@[+"lq&KlS0GHCe-r2Mf%+f1iaSX@A*aKHTT1#Nh@P[arcHKI@&9D@p(l
hi,lmI&aa8KVTmF[[)8mUcS)(@%r8!G%d1VTp1!fVZrLTFU`iXR"irjT1$m(`bF'
6b)49@I#QNrRK&*`F2iD[`Yar9Cl$XFMC4C[(MVmHRMZ*1$[[NC[X4iGVX1ajPhm
&E$rERfPF)N*m*AJXZil+kD%EaS4`QK(h'K&&S4R0#1Bd)paS4qpJ49e,!LXY@K$
Ef+c[fK$BJV2)D%H@d)pPJ4,UQK(6B%D8"kJ"l&JI+61K!MhQ"%A`X#+RIQa(q@6
N3e8)SH#d)Jd)fV3M[fK(%qV[&`2YBlL2$Y+f`fpVV*p6DG[#,(MMc)4@%bdXB91
2eTYai2&RFAmIJEIekAaBh4Y+f6i)3iQI)E!bSZYQD2qr`aIFhd,5bK9@'9$6AAf
[3X$#1ZX1,(C3Uq0jGKKf[$Nm+2%`[qB9FQKVlL,PBa9h"8fNd)m5cPf2N3Tj0"*
!-DrLXEU-bpMa,(%Nd*0'%GKL4erhpACF@6r@1[!c%XiFIjeK`bqh[kA4Xkc@j8+
U1EXk)kH$(0f9M$YU2ee#0E4mU1E([)90RB`VSjS$4E+hKZmhU4cERU`Ul[V8ZVB
Fq`jiH@-,((PfPP5ke6F8[qZpZ+A@QC9,Ul+hT8N"+1DJG4qrVF56`V,ldR"jRX6
Cff`lbjZm(!QcSiia'pbCe*9E(P3PN!#R45&%"%@,Ub0PV&biILjYX+cXUA[l)MC
iA+l0kQVVpaK2!KF)fDc%K(mbrK@i2Ze5h$BH&*SF[QXMek41VCeJdD0(-h'&[XQ
cK*RGMfGEL@GC4blRpd+UldBZNLS#(p&R@4iR(Vb20'M`%P56Ji%Q"1[-#j`5"Y'
Ce+DYXpG&l)5G[(NaHcVF1hlQ&9jXe'k&9QcpMAmhpd+kkal5TierXS)9C[ql6$Z
"Lcf8NZEcClDE1RAT#A[c1TmLd+'9IH%!@P22lcK8Tpp`T8qk5(Zf`lIZ#([$K,Q
ISqalm+lDhdrZ(JBPJa9-'*Yp2e"9c4aq90Z%"EfGjMfiX9QE2f&IXDMh,j3c
FmR%bkTJ9XDp3M&j1*NX%XABepR@E,5CZkXkb61TDM"pfAedZ5m%Z5QhHe`Celi%
iFZN699l)ELj"-#ZN!R6cIX&m'Q,i1R(qZ2pEKYIhXl!RAZdfSEG!TeDEK+6+HC[
(lE%eZeZIdZBc@jI4jZ95pqdedA9iep-cq*mF)VH'a+MHFB[!Ydq0IU,8faKYX,B
rNV25Y+r`VMNh'69X$YMAq&ITD,3[Z-3-PT1p[L$L!0#r",UJPSplIdZVFNBAIk8
M)PiUFaS`m+EJ6X$#N5q+cV,1h[-(#[aQe*3Dqh'%J82&D!N[0i5iEF!&+ZMpG*+
Sq88kq6GDk,pJ#IYlV[SGSQ'bl6Y0*SAGl*1[GV)PpA,6$cA%#&+UTeN8A!G#MQ@
G64i(G$j533jp(a5U95@'jqEr6XDrDhmZrK+hYPCe1bdJ2Fi"0!"2AcIX5mU&E5j
f0@M0E`PC[q3[GR4qI2UD1(2LSiC!(3Sm"Q2$-QVc"[j0YJi+U$0A'C,*+K*&J"`
-E,ZB86+,8q"K&-1@0R[)d%48b!P(lS6HmEI2M3%A8!$S9U!P(m5*#!P(lZc++Br
FA1M&l4!A3FQS(%dmL8ik#j4ITQC-AY8I[KKqh(UJ5pZ6N4@iRF3"1eHG#Nbk*!6
FkPL2FHV%HqPK!%pc0q`'(6@KRd0p9fF%Pk61q,US,A@2Qr3F[b[X'jQc,c!ABJh
3+Afa3kb,k!`mXhYDQdl-irH&Ck4-MZaF!CiDGLh*r$#,'8B"E1"+GhAL3UeMlTd
I&@G2$G#5m#1RCTAMTCZ6X+q1bTG,mA)Lk'0H5lf(%aSe)$03B2`CZmla0hA5Nc[
irEqC`Mh&DQIU`Qe1pVRNQ+@B+&$#"DD3!)D$)Q0A2EM`jQm,1IhE1["MmN`5P4+
aYc&jr*L4G&KiSj[MZ&mcAGc#+,kacBT5lk'PfqH!e0Yr9Xi@FS1Y)PaafiI@e0I
B9mGIbSVb($PBqTY[8K+"c8&"XaVC-$MjHhcl-dL8f6qlF28"TRbXIA"K%d`['Q&
GM`l(RQqU(Bj1f!DPj'h3-iqfZ*-lq&JjZq-b*Dfi[X!hK2Zm",r1NZ4925k`qC8
+J#29iFS#UPJ9MedB84iHqK@f-02,Z)8Zrclb(c,JdLEJK1[CXiL5l6TSjcdeJ$%
HChm18jMpl(YB%k-k$,j%,f-(XkE!AVq`JfcbMD0Ta61[RY@([VFc#QhS02iHS0I
Ud$BN$Ei0HVkdl!lm((`DjIjlQl3FI"Vf1AJhVr-[r[mqiIM+i0m[QhHd[1q[G`m
MLFVT9DP$$qZY-B8'V4L&`J+kFFd&*I'-DMP-JYQ!YS4cEUM#@"Ak%&*A,!Ve&#Z
3!!9q03Vd`+SU&HS"AR%%@-0A&F5SE1i+c6Bl''SLiD@+C$%VQ"0idFhI9(iU-03
E%XPp*1G2R+%Hp2`9#0'IH+%I"20``%I(2YPC+HIVLrc6E[@k&aDI1K8bIaK&5XU
AH8T+AJ8Yc5bDAdDA$KUUAVdY#PckA4TG@1EC@-*I*r[K9Bp5X%HMh6hlD2p2ccC
YcIhVp[6pUm`RbSUi$rUIh#KSccF0+Z[TRSHV06"ppLIeZCHh1eGM5GqEplUijU#
4hXeUG)8"'GXk52SFfE15!AG[(R)A83LMQpfGP-+P3M6)-!4,K9ZZ9IXHX`qHNcR
c1TT+fhXSI+lK-LL!R5Y*RIpfJ#DXUci*Vc9BfSff%DijKT,Ac-rZVL'URc0RIBd
Hi8@1604(HRJhNTd2!6Y&[6e-qR6UlXUcCrAarP'T*2`,5cQI8K*A,AIS@9H9je8
QGm(XPIHLebe-QKY,R!N5l**`AHR9*hhlAE5A0dCKVN#FIceBlXi'aN!Dik3k,#D
5pfkc3jYS1V2P2HXVIp*3L6+fI9U8FL+fRdj`[rHr0HAJ[10bH0R66aXf9[el5kr
"[U9R"[Vql+61rrprVF39CbF2-hl4`QP8[IaZXFl2*6L)mml1AcEQk`YY1MFKSbb
U`XT3fm1R+ZJ1Y$i*D5R-b$kZ3PGEV*m`8q@QNTP'9&i3TkDeXV3#0)Rf*6l$kT2
dbRlT[YVHhbI&AVai&h*fV!T2-#P5TGJdJT[brPp$bI2c[2T[brKp#QmVdV#Qc[5
qGj+$#MRpXG0jrc`%h#"&a6IPmhKU-)#IjdUAmA!a`)p(rlrakhSkH`Zr4eJ#A0K
GdH*BAI'rlrGkcSN('RqSMYf!&mEkJMSrJ-5ajkr3kSl+'0#`KeZ,BhC*Xha+'63
c-[+MXF,Fq(3h@Bhc'lI5pr3hr!b!B5H3!0Gh$U`mD9fe28A1jbq#RmPUE%JIqD9
T1,-ZBq!X#RRjGjH9QEr,b5"FUKNTrcH4ZU%H4P4ZiFXY,TEVapK(Y-MGEc&#ECf
5'qraGf[TZPfp4iF1*$kF2c8qNfZAZmHK[c3"DV8m+q(pMrZrDKVhF2rA&l@lbpp
iqr6dJMcBqlerHDrZYIhHZH%0U!5VV``RKKiVZ*FMJ4l5KPCK$(dXAId,+2!aSr(
bq$(`H!5lQDk2-hP$+Mhf63a33i'CLjP""+2'a4ASC!&lp+"KM[im9+HalR,mD2,
hmHlbpe`Gk3[LT$0NQ(GI$A3q9$diG)S9a2UeAAY+Z5Kp+1mb-A*bcVhHrr9fIhE
6XNXTUT95Ij8RSQIG4E33KMC@rh@B"'rhHkc0b"(dff[mTEA`KpbkN[-%#22@fX)
Ihlh&h@m!M12!r")Tr3R[q"$h%r$#rNh[XAi6Bc@!Tp@(IB[apH1P5MK@l%$2Jkp
T#ZJF93-ki3DX$1'c)P56LJaSY$2r!'G9!`*2m!-pjJCTrm3-k,#66rjJCd1[D)-
DLJX%@N1kMKfH3$(2UrQiNfKNiHrbpe`*EUXE,,kE#qPP&efrSF!ZYh9"JU!!!%&
rU[%!#3#43f4PGP0VC@aPG'pZ-Li`)-3!#!G$3f4PGLj`!3!!!!K849K88%T06D6
9rK'Nee(9!3"X#FJ&!!3!!!!!!!!@(3!!!!!!!!@Q#d0$C'9f5@jdCLj`!3!!"Dj
849K88%T06D6A06bNed6C!3"0"@8-!!3!!!!!!!!'f3!!!!!!!!+r#%0NCAC58e*
$!3!!#'ebFh*M8P0&4+)YMXDNedaV!3#"NfHj!!)!!!9(!!!!!!!!!fF!!!!!$N0
NCAC6Df9XCA4[EL#j!3!!#p448&*+8%T06D)YM3kNee,N!3!d8T0G!!)!!"bR!!!
!!!!!#T%!!!!!"d0-DA0d,R!"!!!@C94&@&435Ne0SrK5,D6A8+%"!!`'[*S!"!!
!!!!!!!eC!!!!!!!!"&J,3eP[GA*$C'9f,R!"!!!D[94&@&435Ne0T0B)@k6@&1F
"!"6#%Gd!"!!!!!!!!!GN!!!!!!!!!ZX04'PKE'pR9A4TE(-ZF!%!!"fS9%9B9&"
+68fNeJeiT0G3d`%!8bFJU!!%!!!!!!!!2b!!!!!!!!!18`K8CA0d)%4PGJ%!!#[
lBf4PGNe+3d1Nee*rT0G5KL%!'m*Ni!!#!!!9a3!!!!!!!!ib!"!!!*cq!!!:
(This file must be converted with BinHex 4.0)

:$e0[FR4*EQPdBA0Y,R"TG!"3593J8%P8)!#3""Yb!*!%-F*36@%d!&9J"+aK)&3
*)[9(TUB*M)bQ8mU01@*H*S@bGP@AHU+5Vmb5"EdXS*C5kPV[03ZC,9N8*-df%-D
DEcp!53q"XG1Z5d9-#8bLL@N@BQUPcLVd@h3N&5Xp`#6U3-,R'1r4QSmr%P8B*&&
R'eKS)K25AdT1D`Ze$Pb`V(E9dKZ69CRGZNe)cMfHPlYq!*lI%J!J%!J%!J(*S$J
%"6NcbC!!"Em!Sa!*lIJ&)"bBJ%%!3#!@q!#!3#h`!@r!(*J!6mMq4i!J%EPbI'c
jQQhi!J%!J%!j$)k!3#!3$NF!8C'mM@4R)`hrEr0r3!+@5L)K2QG`&*UCR[JI&Ba
M'-BaM'-BaM'-BaM'-BaM'-BaM'-BaM'-BaM'-BaM'-BaM'-BaM'-BcaI&)KYk+b
aFE#l@j4Q[Y##,,Bc5&'CFmK,99mQj2*V%ZHeaBklCj&NC6[&)MfQX#,!T03PQ+2
%j18G0C!!e(RLjj!!Y00)d8pESXPQGb0&'CD%aHd(*dGY#H+4'FdMXb)Ga$4R+Lb
M2NG2A4023JLUF5icf3Sm5Ld@5[@bShLN'FA2*iT%[R4RK,Bfq1R*Ri[LN4%3dk2
FNb$P8MjY+TC%MZ!D3JM4%#$l$e-,*,NK&"M-ZH3Jk1%MmF4%JH,iV'-BaM'-BaM
'-BaM'-BaM'-BaM'-BaM'-BaM'-BaM'-BaM'-BaM'-BaM'Iii0b`J!KP)$VBEGV&
HF2rNr$,NVAaXr!0rii,NSL)'kh5bKJ!S0*GSTT%KDFA'+4%4!h@kH1#M-#5!e6H
bKJ!Sq2fLQN5&TaFBXS`LQk%j*!DT[ic,E"LL+*C3`!8"EG*'pD+-bfa"LL+)@4*
TT(IPU12a`*)$90l+'!#J,bH"!V46+1)`e-R*)$90rpmE2`$B@31R([YEB$k1Q[Y
##$ZrcfQX#,9klCll3NTpjj!!#Ne-Le0S4$M`9&`Ta#'fd)XY0014DrY!K4NZB5b
A"I9`$M`DdA#R&ZNe#He0S42Y!K4NZB5RJad%m&!!5d9bETZ()iYdQS6fTY#*pS%
+-Pc#@#qVJ!)G"2"3,4A*ZQiFMLFR+1Q@QQR)YIrDq!'`C3FI1I9rD"#M*F`P2"M
Q3AeF#dA&4EaFmKET03RY6D%6l4l,-T2J)lNhAE4GM+6iZH3SmQkrY#5Rd1dY"h*
ZFH#qd#&'5jbGJ[Ui!#(36`8#d9bETZ()iJFM5#MbEVra5QBD*bNbjj!!M#0%ibR
4QRrD"#M*F`P#L0(i!+6812"@Li8iM#0%ibR4QRfj1[i,"2"3,D,'H8C83Spp[LP
S33ffZ3KScP3Pikf3!,8fLAV+3R*KL[NF[lIY#$Jf5UHhMJGJqhJ9SUmGE)8JcLA
cSc`PL)SXJrpS%+-P!jK,#h-KEf6Kiq`m2R-J[Ui&&AV+3PQh3KScP3R*KL[NF[l
Im8K$DD*AVC8Ea4RaLh6FcPArYI!$B-S1(cReIfJ3SbA-*3F"FN""m'$lF(fac),
kZ"4F9&[%V2bj+qd#&'5d(Eac),kZ"D,MVC8*[ID2!1RB%@C4fb@d83fQLMa4RpT
m-)C3F2R2Urm8TQ'Lf-T2Ljj#"b0)+2*ZXTQ'LM-ZH3YdQS@TY&XEI&6N*i`d@qT
UT$513Y00)erf[J"X'8((cReGY&FLdGP)5mGE)8JcLFLe"1qd#&'5jK,cb!8QTN@
TY#)FH2d984-5h5DQ4DQd)K4Q4irpS%+-Pc#8mI1C"I9`,4F9&[&([Y(XXbNq!MZ
6GGY&f-T2L6FP-IY!K4NZFRB,kZ!!Kd,GD+U)Q*!!14T"4j0eP'C3YhfJ3SbA16V
E5d(FQjd)IY&9%6%Jl5d+2*ZXSc+%2rpS%+-PX,FG$*,D,XE&9+2*Z@aP*ppVi!E
@%2R3b5fLl'ha8j!!JFM5#QJd8H6GG[fYT3b`QQKq!#Ne,4Bb#QDD(%0*N!"b%dD
DIEiT"C+1+CKSKT-Jj#FQQP8Z-64Ljj!!R*S3KScP6-L2EL'SL#&LD-q,M&cb&XS
jb6la5MbEN!$5C"b%(+"`F*'H(-Lb8A,iiPUNF5ia4l2rY!K4NZB5`6aq!FHh@d9
IDGaDiZH3!)16$'Fic`rDI$$R*d("JqFHh@d9DT(%RNddM[Y!K4NSC3F%G##YSZ`
LDF4P1*k1&iXG1ll3)8C,QfX%pZJ!)G##Y&`TaG(K%)4*iHHqdq'(16X))ipZYSU
e51*'bNF8Hqha5@U4a,RN+DQiFML0)+2*ZXSc+%2rEpVE!IQr3e!pckT(&YTDHqU
4aED@J3aXIY!K4NZED`6fk!G##YSZ&1+2*Z3L6`mppTm-1FRB34alGE49UNF5MbE
rDI$#'CbG"j)FHh@d9DT(%K%RKjiiXA'a)19H4IKU"lRe51,E5dYqf&YJ2X)I1I9
)iYY,3)Bf2fq+6Nh6F14aFmK5)ZAa4j0b'Nb$N!#AfRG'H%KU22IpS%+-Pc#8pZ1
2$rfq+6b16),,RN*CRF3KMBjN@@EI(6N,RN,C4cNRa4j0b'SmmA2)8d$h%DD&UE4
hLP'3!&(XJXK%$dGY##+TBA*VNFF5aV@*FmQrqqCh"$'a"ID"#M*F`P2$jalGE49
pTh%04jiT%A,iM66hc1i)Bf)0EpS%+-P$+$JMS3AfJ3SbA0YB*lG!1K"ID%P2XNJ
RYad)+!FH#Y&f0[LTb&0!pa'QRfJ3SbA-*6`4d,HYSVNh6F14a5$1)6A)llIY'ha
[0YB*i+"E4BV+2&cb%*TI0pqeY+'C[d032F1j(Dk*TfLaN!",-F5e512q+5Ld*AV
C8Ea5$1,RN!#AcSc`PXEI(6Nrl3)8C,Q%TlFFH$IDq!'`C3FI1I9fd9b,4f8K,ae
XK5$1*b,8%ll3)8C+'8("(3JhfJ3Sb8-S1#1K(rY!K4NZED`6`D!!Kd)0D,K6L"P
m3L6`mprLP'38H)16$'Db'Smm8e""$L@U4a+2IpSfq0jYV"2"S(fYJfA0qJ+J[Y2
KK$+$Jaai0rf[J"X'8("MS3E`&3AfJ3SbA-*6`BjN&pA!Y&a8@m5qG'H(l3)8C,Q
fX%m&!!3k%IY&`Ta$mfL%5H(R[m8QSpaLN!"R%Y0M6D*I1M2$rfMEihQfX%m&!qe
X'bj[d"8'qdq'%-S1$((J[YI!$B-S1$(3MrJ+JhfJ3SbA-*6`4c),kZ"D,LSYiPm
k-m2fJ3SbA16X)-Fb#qVJ@LiU,H)'Aa#*2$chrD"#M*Fj1`Mjc),kZ"D,LSYiKqE
4,jdCiIqd#&'5jbG"`B%Fb#qVJ@LiU,H*D#*YaRID2+pE+MHYY&M2+-U)5qG'H%Y
MEikFRfJ3SbA16X&pA!!3k%&D,K6LFLe"1qeX%PcISDJHiGbEfLaN&'C'FdMML@U
4ara5jj!!T%A,iSmQj4@@&bDj(&cfTPcb%Y0M6D1*CL@0Da,RNhc)XP&bq,Ff8Rq
+8L,Pm8H6FSciaD,Nha-l6P8K$EDk*TrpS%+-Pc#8pZ12"@d9CP(E)@QQR)YIfYR
m'Ep!G1I-SlC!L6qd*+I@$mNEd%p[3$M`Dd9T&p'HZLDIfMcB3fbS"0P*rLPZE+3
ZH3PTXDE44j0b0P)iZH3T%A,lrY!K4NZB5`Yiim&E49Q8GXKDDDFLerD"#M*F`P2
EMM`DfLY)[Sced66,666N@[rYE2i-hk!kFqC4fb"%RpSmf%0XU!6C5IiTEQbN,RN
+4&bq)1eXU&'IfrD%P2V"q50k#HhS"ai+d9CP(E)@QQR)YIfJ3Sb8-S1#1K"ID"#
M*FfeJRYd!k%&pS58qb5#Hh(3JS"ai0D+dLqM2A40-Y0014DrY!K4NZB5RJad,HY
SXd'LQJHiSmQrfYRm'Ep!G1I-SlC!L6qdHE#'f9!*XT2ra5QBD,R+TFmK632F8H6
FiJj31$K)c`NdBDQ5NqL)3dQ3!-T#FQYRND,RN!#$MGaYrm032F1j0rY!K4NZB5`
YiipZYSZ*SciMfiZ-8d$h&(NhqeYJ2cIVjRF%-E%'Y&`Q,&6LMa4Q4R0)llI&)"d
jmbMYN!!L6++bd5R4%MbUA2DiR*bMTV,RN!#%5H(RL0),RN*I1M2#@*Scj'[&,M%
(+T(JLa%8@8N+-bK"Cri$TcjP(E)%5IfJ3Sb8-S1#1K"@dAB401+%&pS%+-PcE@#
H#J(3JVD,K6Ljj#%5H(R[Y2KK$+$b3k%&E4Bcf%8D3K%RKjiiXA'a)19H4Ifi"Yr
lI&)032F1j(Dk*TP&CFmK"aZifj'N&cb%C6NF3KMBjN@"-8ea4iNQC6#mA4h4ILN
T2SL&(XJXPQGb0IiDJHiGb1ed66rlA`!f$+$Jad-NYSZjR)A'*ScIIYE!10j[emc
Z#'0L#Y&M)*CML`Q*Sa4llI&)D6)13Y##%dDD%Xa0*S33ffZ3!*I'GV#Ka14I'FK
16$&I)jCDQd6Nj4drq%dd2`!8QTpS%+-P!jK,"I9`!%1KEQ3Yl*`mIBH(k+j&mCb
%0'FU%j--9mMPrD!!d**92EeY&FJLD@K,l@bS8KfYdqhl3)8C,Q%[2*J6P(62DDF
LeR(JU+j0MC51*bFSkCDDDFLerENk"9f#H#J@d8198B(+U0r2Ym8M+1)3ffK#bY1
MS1%4Ircb!8QTN@TY#*pX1AR*d%F#rRN`*bMTRY014DrYKbmj1JMJAYY,3GbErE$
PjbG"H&%D2`!8QTpX1AR*d%F#qha5(6AfK""h&&CFmK1-TdCSA2DiScAfK"&Pcb&
S10P)8CPcb%Y9AbENmQXImG0ID%%(GrLPK6Ljj#dddj&V)dJZH3YP(15I%HdeJ4B
&*U%ibR4QKDQd6Nh6F14a4lrY!K4NZFR3F"B-(i6S39S[1eL3!1K)dJMfQX#,!T0
6l4i"diEGV%pTTb,AE4F+F4K'Ldddj&Vqhl3NTp#L0(i!+6812"[Y!K4NZB5RJMS
*i0!YSVNh6F14a'%D,666N@[r&,Bfq+R)5iJ-K'N&XCT#e0SY##'feb&'C,99mQj
2*V%iZH5CEQbN+2&'IrD%P2Tl6@"&UpGXmFH2rD%P2SkDqd))1iim&pS%+-Pc#8m
%G##qem!0X`P2(cS39Y&f0[LTb%Z)$*pS%+-Pc#@%%G#$@d9bETZ()iPa!C2Yqf(
,cNk!Xq5!dYY&d))EEA)8CNY9AbENmQXIYE"XY$6$TVl3JPSXC")jaR(<2[Yqd
#&'5jK+H#1K(lD+j0dh$NF3GTDID"#M*F`P2"((JeY&jlAC!!@A2)65,k-pG%drY
!K4NZB5RMjai+fLRY0B%@Vefcd9NXbMYNqd#&'5jK,#$(3JVD+Y1*6%Pa!C2Y(Q`
KYP3#E+5fLlQbN!#Ma4RrLPMVYRLM-ZH3!+D$41-TdCTrfJ3SbA-*B4mim&E4F+F
8d'Ldddj&Vrl3)8C,R*d(!@$"q%k%&D,cYBN1K)dJMfQX#,!T06l4jp1'hDa2DDF
LefdA(AE2&(LM2lI&,3JK0'QK,-5"k2&aL@mJJRrEJ'hrm8RY6D%3ZH3NFicLfdY
#$P8Jj%aM2$rKTKdepS36lF!frp[LXBaM'-BaM'-BaM'-BaM'-BaM'-BaM'-BaM'
-BaM'-BaM'-BaM'-BaM'-BaM'-raIm8Lb*()89Pcb&XCT#jlA&&FmKaBkGa'N&cb
%1$4`f6N@C4fbCN3lLFQb4bNAiT&XDI1-)3dmNbjj#eML*(EA40-SV*bNbe0SScA
fK"&Pcb%1R(LFLc+1f6a5+-bjj#@UVj0bFLc+1f3T%4%cmAa@-BaM'-BaM'-BaM'
-BaM'-BaM'-BaM'-BaM'-BaM'-BaM'-BaM'-BaM'-BaM'-rhqdl[m8T%A,iY##'f
eb%Xfk%!b1-M4,aeXK"bU@`LDG'H%Sm4T%JZH3PpVC8rl3)8C,3H5!`-G##Y&QL0
&S1-Ta$mP%(+[)[mX401#'0MpZ@%`CK+b#qVJIE#f`(f%%GPL*T`3aXIYm8ScMdG
#4!C#$&)l+N,Y$4DQdA2)A'-)f-([mG125CR#0IDVP2V!r"2NN!!Y&a8@m@QQR)Y
C'N%'+4f9)AD'LbY1ApSm1R(J(GU45)L)U,'FHMS5)$)3BT(C8KGSDqdH(6Mf502
PfLaR(Sk%L!b&cb&)02Lhe2@&(ID2$Tal,8FXcV4F+FA2)@R1-0&XSjCRID2$Tak
6M0S`dZd@-ip(3N3'3ZH3!)DM0S`d@qTk`Sll4iG12!8QSZd9U2FBT"R&ZNe&rEp
Z@%`CK+b#qVJ@LQ8F6Nf0P)j9,&aYLLXL$4`6l4iG123ad)E#Zd@-ip(3N3'3!*U
1K$B9rD2$FSkFHYSZTY&b"lL4U2(&aMIiT04AL*T9,RN+-j!!BJi`Hrl@cq#`aAL
*T9(6N!"QaJprLPXEI&6N*F3'3M5#("SiE*b,-SlC#ia"b&TTT'[qd*+IAqdlJXJ
G12((MrfK*6krfRFFH#qd#&'5jK+H#1K"IDq!'fB5RMjd)+fLl'ha8j!!Pa!C2Y!
K4NZB5`JMS3DfLZ6G0`j(%Z)$*rLPS33ffZ3Y%pUE3L&)-iZH3K`D1'bFLc+1f6r
YKbmj1J,2NJq2fdA3JKYYFKD*DU[)NeL6fTY#*EpVB0PSDBG0ID%%(6MeSXC")ja
R(<2[qd#&'5jK+H#12EVD+j0dh$NF8H+-b2E[m8YcC5&'CFmKE'D6rY!K4NZB5
RMjai+fLV-TXK4@8CNH2rD"#M*F`PJRYd!im'YSV5,k-pG%dlIY!K4NZB5`Jad)+
fLV6L8a*F3'6l4jX)EC8!QbNYSZjXT#Ma4RrLP[T83PU13SpN&P-h&S4bDD95M0I
D%%4VrYb`Q#XJ[Ui(fMckGJ4B3fQVD+j&Q8GXK#'de'H%M5*(rDq!'`C3F2R2UrY
!K4NZB5MTal!0UZ+(-J[Ui(fUj6kqCh+pGXm'kh6l4i"di0eZM@"&Q8GXRfJ3SbA
-*B,kZ!!Kd),l@dSCFP'E3kFH(3riT4l),,3MNddUPcb13iPQ*bEQbN+2IpS%+-P
c#@%%Fb#qVJ@LiU,H*b,-SlC#He0S42Yqh,#B-j1XJ[Ui(fM`!@Q"&j+)L@d94D%
Y9AbEP)L)RfrD2B0mT-#,-SlC,D+j0cC5&([m8YMEiUFKFmK$S5ia+,3T"R&cb%1
$4`f6N@C4fbIq5M0SG12$SIY!K4NSC3H5cS@kfLVl6Z)DMca$S5bE+5rYmF'MKXG
#%-E(lA`!f$+$KmjpApS%+-Pc#8G12B"Y9a3jN!"I9`,4F9&[%1$4`hpS%+-PX,F
Fb#qVJ@LiU,H,RN)G$pSm!kGJ4CP(E*pS%+-Pc#@#qVJ!)G##Y&`QiSmhhl@dSCQ
r6fQKYj!!G12@LaN&-h(%SY#jlA%1Krl6iB3bJi-G#hIEPJ9HFR3GZ(cS@ll@`3E
cISi0($Bk%)Bf2rDq0eN&pA!qdHI6X#,#'dep[fJ3Sb8-S12R3J[K0+jaR@rD"#M
*E##1C"I9`++j0dh$NF56jbU@aQNqhlA`!f$+$Mjck[l3)8C,B34c),kZ"pZ@%`C
K+b#qVJIEpS%+-PcNlPU12a`*)$90cQ3AeF$l4i!,6!LmP%42qhrY(Rq0LH)MZqd
q'%-S12R2Urqem!0JbJi-G"I9`!%SZaQN)'ElpVD8-cIZ"!iaZqhl4k824iE-qmJ
JRKTKdepS33G12ID"#M*3bJlFG##qeYJ2cIX*TA1-llI&*q1q)LU6N!!iaZrm#"a
MGpSp+(Sm0QIH336r&),*4aFmK$S5ia+,3SV+-bKEML@BKT!!YY6,664FmK14CP(
E*rrjl63fmJkFHrlAaZXJ[Ui(fMckGJ4B3fQ[Yqh,#B+b#qVJID2!"DB%ANSL*E4
9&SA2)5e9I*Z8L)LIEpS%+-Pc#8pZ1C!!AeF#dA&4EaFmK2DQd)RfJ3SbA-*4dip
J'eA&$Q3AeF#dA&4Ea$JdF0rD"#M*Fj1`Yac),kZ"D,LSYiZH3Kd2fUj6kqCh+pG
Xm'kh5dA&4EaFmK6eZRfMal6@"&Q8GXRrErf[J"X'8((cReIfMf"&bZFChfMEihR
*f#qVJ!*pVB0PcISDBG0ID%%(6Mhq+5diZH3YGcSKbR)[rY!K4NZB5RYac),kZ"D
,LSYiZH3R)XbMYNqd#&'5d(NXI1C"I9`,49UUmL6@*`KYP4'MLfHe2#MAfMckGJ4
CrFjGY&@R%dNM5JR&VZG%18j&riT$6SmK4iM+FA2*-P-@YFKFmK14H5L)RrD"#M*
F`P2EMQ3AeF$l4k6G(N`)XbMYNrlA`!f$+$Mjck[l4l!LjA1-ll3)8C,B,kZ!!Kd
),l@`E,3d`kDqd))1R([Yqh,#B-j1XJ[Ui(fM`!aDebB%ANSL*p[f[J"X'8((cRe
IfMf"&bZFChfJ3Sb@`AeF!"$S3AfYJf@KTKdepS33G12IiT!!FRFMLN#+,H,3JKF
mKC4K&0dArrpS%+-Pc#8CPYJa4&%!3I1K"IDq!'fFR3H5`4ck[l3)8C,Q%VkXim&
q5%8@m%-E(l3)8C,Q%X))im'qh,#B-`P("FP%4!h@k36`8$l3)8C,R*e[R*F%m'J
($JSc!NJ08hJRJS(fMf5%8@m--*rfJ3SbA-*B*i0!1K"IDf$CFhlNK&&["$'arl6
iBFj1JmPJMReI[UEE)YFSHMe[fJ3Sb8-S1$(3J[YEB$l#D9cM1rrr!JLD@Jl[YEB
$mhkqTYXLebKk2IEp[LP$&H)QP8G13CXB2<bb8a,RN+-ip(3K04d)E$r`aAL*T
9(6N'E'$hrDq!'`C3F2R2UlD,[T83Pikf3T!!Ca14DJRID"#M*D$Jac),kZ"D+e(
3KX*$S5bE)'qh,#B-`PC"I9`,D,S33ffZ3KU-fM$44Q6bDaqd#&'5KP"f!ad),l3
)8C,Q%X))jN&pA!Y&N!$M6lFbq)DM0S`epSm!kF'S03ad)E$E4Gp+L&(Ljj!!QSk
%0Kq6dkEif%-E(lFX*Jc#9N&pA!YSXc&)L*b19Z0YpUZ8qX(`3+#I*)&SZ)QYN!#
N'F6N@S*hfM`%c@K)Bk%0KYSSLF6CbQb&)6YRL6+5I,qhl3)8C,R*eJq#"36j*!1
K"@Li8iR)Y36[YI!$B-S1$(3J[YE5KQEpNp1Q&NUfLaN%$(&(PN&NVlA`!f$+$Ja
d)+fLlDRXJMIIYE"XZEpNp1Qq0K$'aY&M)+CZ1)3aXIYqdHKL[%biBk%0Kqdq'%-
S1(cReIfMdSHM`fCpj""2Yq6dkB@5[Y(SBVa-Z'1K$BIY`$Erq+5qG'H&Ca*fhq1
R(X!fUiTpX1AQfZ3("SiEb([QGb[AE2"ZYdqf(,cEA*il)2QGb[AE2C!!p[N)8%e
K0!,H`8NS+k&KVUT5%*M1fS`TR+brHD%GV#LrJNXL6#,3!#iFCV*'D#c,A,KGE+Y
X492##"A+U)$D5h&cr9*)CE)E,d!T&+Nj)[Pa4qhb-Kj&99L3!0SK3@dm"$DK2Tj
AL['bG3R$De0'DK`$,+UQ&8[1@+P#C)MXJ2QU%GAa[c!8LhPaEc33c[Im(rJY3&"
&EQ3pY`!!!:
--

David  A.  den Boer
Musi Computer Products
Macintosh Users Show Intelligence

[e-mail]











Path: ucivax!gateway
From: [e-mail] (Wade Williams)
Subject: Strange Think C problems
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 30
Date: 6 Aug 92 22:08:40 GMT

I'm using THINK C 5.0.2 on a Quadra 700 with 8 megs of RAM, 32-bit
addressing off, VM off and TuneUp 1.1.1.

The problem is, the debugger keeps crashing in between the time the program
finishes linking and the debugger's windows appear on the screen.

After such a crash, double-clicking the project file results in a message
that "the application that created it could not be found."  Double-clicking
a source file results in the message "..could not be used because it is in
use."  Double-clicking the THINK C applciation and opening the project sets
everything straight again until the next crash.

Does anyone have any idea what's causing these crashes?  Is there a new
version of THINK C for the Quadras?  I've experienced this problem with no
INITs.  Again, it happens before the debugger finishes loading, so I'd
think that would rule out a problem with my code, wouldn't it?

Another interesting note:  trying to open a log file with MacsBug 6.2.2
usually crashes the machine completely, the only escape is pressing the
restart button.

Any help greatly appreciated.
-------------------------------------------------------------------
Wade Williams                        "One likes to believe in the freedom
User Services Specialist          of music, but glittering prizes and
Academic Computing Services    endless comprimises shatter the
Auburn University                 illusion of integrity."
[e-mail]                          (N. Peart of Rush)
--------------------------------------------------------------------











Path: ucivax!gateway
From: [e-mail] (King Rhoton)
Subject: Re:  Strange Think C problems
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 4
Date: 7 Aug 92 01:41:01 GMT

I think you must have a corrupted system.  I use think C 5.0.2 with no problems
on a quadra 900, 32-bit on, caches on, and over 54 happily ce-existing
extensions.                                                ^^ co
King










Path: ucivax!gateway
From: [e-mail] (Dana S Emery)
Subject: Re: apple.com (duh)
Message-ID: <[e-mail]>
In-Reply-To: Your message <[e-mail]> of Thu, 6
 Aug 92 14:43:24 MST
Content-Type: TEXT/plain; charset=US-ASCII
Newsgroups: fa.think-c
Lines: 17
Date: 7 Aug 92 01:49:08 GMT

oops,

it has been pointed out to me that I mispealt 'anonymous' in my previous
diatribe, for which I must appologize, that was a most egregious error.

I suppoose I could blame the lack of a spelling checker in Mailstrom, but then I
would probably end up with the task of implementing it, so I wont (hope adam
isnt reading this :-).

Luckily, my proclivity to mistype that word doesnt usually block my access to
stuff, because the Mac program I use for ftp work (HyperFTP) has spoiled me by
provideing it as a default, thus saveing me the trouble of mistyping it.

GUI GUI gumdrops.

Dana S Emery <[e-mail]>











Path: ucivax!gateway
From: [e-mail]
Subject: Graf3D Library.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 7 Aug 92 14:58:45 GMT
X-Vmsmail-To: SMTP%"[e-mail]"

I have noticed the "Graf3D" library included with Think C, but I can not
find any documentation about it.  Where could I find something about it,
and some sample code perhaps?

Thanks...
Will










Path: ucivax!gateway
From: [e-mail]
Subject: Cool Black Menu (tm) - now I know
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 8 Aug 92 01:40:46 GMT


You may recall the Cool Black Menu (tm) question I posted two weeks ago.  I
found what the problem was.

Some time ago I have defined some menu entries as having colors (ResEdit
automatically created a corresponding 'mctb' resource).  Then at a later
time I have redefined some menu entries, and removed the color from some
entries that had it before.  However, I did not delete the corresponding
'mctb' resources that were created by ResEdit.

I do not fully understand why that caused my problem, and whether this is a
QuickDraw or TCL's CBartender issue.  But ever since I removed the extra
'mctb' resources, CBM is gone.

Thanks to all the kind netters who answered my original post.  None had
guessed whodonit, but a few people found this feature cool indeed and
wanted to know how to do it.  I could not tell you how to do it in a
controlled way, but you have enough info to get started.  Tell the rest of
us if you find anything interesting.


Chuck Shavit
[e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: RE: INITs, cdevs, patches
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 8 Aug 92 16:00:53 GMT
X-Vmsmail-To: SMTP%"[e-mail]"

This works with tool traps:
oldTrapAdd = NGetTrapAddress(Trap,ToolTrap);
NSetTrapAddress((ProcPtr),Trap,ToolTrap);

You call the "oldTrapAdd" varible in your (ProcPtr) to call
the orignal. Like :
CallPascal ( <Varibles>, oldTrapAdd );

There is somthing slightly different with OSTraps... the
varibles arn't passed on the stack, or something... (I do all
of my programming in C, and know no assembler.)

Anyone else?

(I also have a simple INIT w/source that every time TEIdle is
called, it "shakes" the mouse randomly around the screen.  If
you want a copy of the source...  just mail me.)

[e-mail]

PS. No, I do not know why I wrote it.










Path: ucivax!gateway
From: [e-mail] (Robert Olsen)
Subject: Bug in CPane::AdjustToEnclosure(...
Message-ID: <[e-mail]>
Content-Type: TEXT/PLAIN; charset=us-ascii
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 28
Date: 8 Aug 92 19:26:36 GMT

   I think I have spotted a bug in CPane::AdjustToEnclosure(...)
Remember,  AdjustToEnclosure is called for every sub-view of a Pane when its
size is changed with ChangeSize(..)

The bug comes alive when you have a Pane with size FIXED in one dimension
and size ELASTIC in the other.  When its enclosure changes sizes in both
directions, the AdjustToEnclosure has to move and re-size the sub-panes.
The bug exists because ChangeSize is smart and will try to validate the
portion of the Pane that is in the old aperture and the new one.
The problem is, when we call Offset(..)  first, the region it has
invalidated will get re-validated by the next call of ChangeSize(..)
So, I propose to fix the bug, you simply change the order of the two.
This way, you still get the pretty effect of ChangeSize(..)'s validation
when there is no MOVE or Offset(..)

   The logic of the routine reads:

if (moved) {                            //moved is either horiz of vert
   if (sized) {
      Offset(hOffset,vOffset,TRUE);     //the bug... I propose changing order
      ChangeSize(&delta,TRUE);          //of Offset and ChangeSize here...
   } else {
      Offset(hOffset,vOffset,TRUE);
} else if (sized) {
   ChangeSize(&delta,TRUE);
} else ...












Path: ucivax!gateway
From: [e-mail]
Subject: Looking for a Think C implementation of sockets
Message-ID: <[e-mail]>
Posted-Date: Sat, 8 Aug 92 17:00:49 EDT
Newsgroups: fa.think-c
Lines: 11
Date: 8 Aug 92 21:01:17 GMT

What I currently want to do is to send some data from an SGI
(unix machine) to a Macintosh. Both will be running applications,
and it is possible that the Mac will also want to send data
back to the SGI.

Is there any publically available socket implementation written
in Think C?

Thanks,

Steve










Path: ucivax!gateway
From: [e-mail] (Jim O'Dell)
Subject: Looking for a Think C implementation of sockets
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 8 Aug 92 21:01:17 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 9 Aug 92 05:25:16 GMT


What I currently want to do is to send some data from an SGI
(unix machine) to a Macintosh. Both will be running applications,
and it is possible that the Mac will also want to send data
back to the SGI.

Is there any publically available socket implementation written
in Think C?
-----

I'd be interested in any positive answers that you get.

Jim










Path: ucivax!gateway
From: [e-mail]
Subject: Sockets
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 10 Aug 92 01:14:05 GMT
X-Vmsmail-To: SMTP%"[e-mail]"



A think-C sockets library w/ source has been put up in the incoming directory
at "ics.uci.edu".  It seems to be the only copy left in the world, so please
take a copy if you need/want it.

(I'm not sure what the standard protocal for sending files to the list, but
some one requested this and I'm using this site as a drop-box.  Someone please
mail me to tell me the correct proceedure.)











Path: ucivax!gateway
From: [e-mail]
Subject: Cursor Shake
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 10 Aug 92 14:10:11 GMT
X-Vmsmail-To: SMTP%"[e-mail]"


    My silly INIT that randomaly moves the cursor around when TEIdle is
called is now also in the imcoming directory.  The code is awfull, and I
don't know it if will work under System 7, but it did under system 6.

    It's all yours.










Path: ucivax!gateway
From: [e-mail] (inei)
Subject: Console-like interface needed.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 10 Aug 92 14:19:03 GMT


I need a console-like (cshow) like interface for a program but with
the ability to install my own menus and use command-keys.

At the mement, when I use fopenc() and cshow(), I cannot use command
keys.  I would also like to be able to resize and zoom the window.
Does anyone know if it can be done or has someone already done
something similar?

Mail:  Nick Nei, Computing Science Dept.,
       Glasgow Univ., 17 Lilybank Gardens,
       Glasgow G12 8QQ, UK.  Tel: [phone] x 5457
ARPA:  [e-mail] USENET: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Sources
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 11 Aug 92 12:20:09 GMT
X-Vmsmail-To: SMTP%"[e-mail]"


The name for sockets, for think c is :
/incoming/sockets-thinkc.hqx

The name for the silly init is :
/incoming/cursor-shake.hqx

    Before I was able to do a directory listing, and I'm not sure why.

Good luck.










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: sockets and cursor-shake
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 34
Date: 11 Aug 92 17:08:46 GMT

I moved the files [e-mail] uploaded into the main
archive area.  Here's his descriptions once again.  Please reply
to the contributor if you have any questions about the contents of
these files.

/*****************************************************************************/

From: [e-mail]
Date: 10 Aug 92 14:10:11 GMT
Subject: Cursor Shake

        My silly INIT that randomaly moves the cursor around when TEIdle is
called is now also in the imcoming directory.  The code is awfull, and I
don't know it if will work under System 7, but it did under system 6.

        It's all yours.

[saved as: /mac/think-c/appl/cursor-shake.hqx; 7K]

/*****************************************************************************/

From: [e-mail]
Date: 10 Aug 92 01:14:05 GMT
Subject: Sockets

A think-C sockets library w/ source has been put up in the incoming directory
at "ics.uci.edu".  It seems to be the only copy left in the world, so please
take a copy if you need/want it.

(I'm not sure what the standard protocal for sending files to the list, but
some one requested this and I'm using this site as a drop-box.  Someone please
mail me to tell me the correct proceedure.)

[saved as: /mac/think-c/appl/sockets-thinkc.hqx; 168K]










Path: ucivax!gateway
From: [e-mail] (Mike Lyons)
Subject: Weird problems with THINK C 5.0.2
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.2 PL11]
Newsgroups: fa.think-c
Lines: 72
Date: 11 Aug 92 19:10:27 GMT

Watch out, major use of bandwidth approaching...

Is THINK C 5.0.2 broken??

Below is an excerpt from a MacEnvy report for my machine:

Machine:          Macintosh IIci

System:           Version 7.0  (2808K)
Finder:           Version 7.0
MultiFinder:      File is not present.
Localized For:    U.S./Canada (0)
File System:      HFS (Hierarchical)
Debugger:         Macsbug installed
RAM Cache:        512K, cache enabled
Current App:      "Finder"

Monitors:         1 screen device
Main Screen:      640 x 480 pixels
 Pixel Depth:     8 bits/pixel (color)

PRAM Status:      Last write valid ($A8)
Modem Port:       9600 baud, D=8, S=2, N
Printer Port:     9600 baud, D=8, S=2, N y

I've also applied the System 7 Tuneup. I have 16 MB RAM,
but 32-bit addressing is off.

THINK C exhibits the following weirdness:

1. #pragma once appears to be fully broken, i.e. files are included twice
   even though the #pragma is used, I had to resort to the
   #ifndef _HEADER_H_ ... method.

2. According to the manual, option-click on the title bar of a source window
   brings up a pop-up list of all files #included in that source file. Not!

2a. The same thing happens when I option-click on the title bar of the project
    window (nix).

3.  option-double click on an identifier name is supposed to beam down to
    the place where that identifier is defined.  Usually all that happens
    is that the watch cursor flickers, and then nothing else happens.  Is
    this function unable to find definitions across multiple files? sigh.

4.  I was attempting to port the sample code in the Apple MIDI Management
    Tools 2.01 from MPW to THINK C.  THINK C always complains (illegal cast)
    when constructions like:

               (Str255) CtoPStr (etc...);

     show up.  Does this typedef

                         typedef unsigned char Str255[256]

      in Types.h have something to do with the problem?? :-(

5.  This isn't a bug, but rather a complaint.  Shouldn't multi-file searches
     automagically sift through #included files as well (and bring them up in
     the search checklist dialog at the beginning)?  Would save a lot of time.

Mike
--
================================================================================
| Michael D. Lyons        | Telefon: [phone]  | EMail: [e-mail]    |
| BinTec Computersysteme  | Telefax: [phone] |                         |
| Willstaetter Strasse 30 |                          |                         |
| D-8500 Nuernberg 60     |                          |                         |
| GERMANY                 |                          |                         |
================================================================================
|                 BinTec --- UNIX Kommunikation ueber ISDN                     |
================================================================================










Path: ucivax!gateway
From: [e-mail]
Subject: CTB Tools...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 2
Date: 11 Aug 92 19:56:31 GMT
X-Vmsmail-To: SMTP%"[e-mail]"

Does anyone know where I can find some Comm. Toolbox tools and/or source to
them?










Path: ucivax!gateway
From: [e-mail] (James Meiss)
Subject: Please explain this trivial crash
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 51
Date: 11 Aug 92 21:33:49 GMT



        Can someone explain to me why this simple code crashes with a bus
error under Think C 5.0.2?

******
#include <stdio.h>

#define ORDER 4

void MatrixCopy(double a[ORDER][ORDER], double b[ORDER][ORDER])        /*Replaces
a by b */
{
    register int i,j;

    for(i=0;i<ORDER;i++)
        for(j=0;j<ORDER; a[i][j] = b[i][j++]);

/****
If you replace the above with
     for(j=0;j<ORDER;j++)
         a[i][j] = b[i][j++];
then all is well
****/
}

main()
{

    double T[ORDER][ORDER], U[ORDER][ORDER];
    double a[ORDER],b[ORDER];
    int i,j;

    for(i=0;i<ORDER;i++)
        for(j=0;j<ORDER;j++)
        {
            T[i][j] = 1.0;
            U[i][j] = 0.2;
        }

    MatrixCopy(T,U);
    printf("Done\n");
}

    James D. Meiss
    Program in Applied Mathematics                   [phone] office
    University of Colorado, Boulder 80309-0526            -4668 secretary
                                                                              -4066 FAX
    [e-mail]












Path: ucivax!gateway
From: [e-mail] ("Jamie R. McCarthy")
Subject: Re: Weird problems with THINK C 5.0.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Mike Lyons" at Aug 11, 92 7:10 pm
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 51
Date: 11 Aug 92 21:44:37 GMT

> THINK C exhibits the following weirdness:
>
> 1. #pragma once appears to be fully broken, i.e. files are included twice
>    even though the #pragma is used, I had to resort to the
>    #ifndef _HEADER_H_ ... method.

You are using "#pragma once" right?

> 2. According to the manual, option-click on the title bar of a source window
>    brings up a pop-up list of all files #included in that source file. Not!

It won't, if you haven't compiled the file successfully yet, or if all
the #included files are also in a precompiled header.

> 2a. The same thing happens when I option-click on the title bar of the project
>     window (nix).

Dunno...

> 3.  option-double click on an identifier name is supposed to beam down to
>     the place where that identifier is defined.  Usually all that happens
>     is that the watch cursor flickers, and then nothing else happens.  Is
>     this function unable to find definitions across multiple files? sigh.

Actually, all it does is try to find the first occurence of the
selection, just a regular find.  I believe it searches all the .h files
that an option-click will reveal--i.e., all headers that aren't also
precompiled.

> 4.  I was attempting to port the sample code in the Apple MIDI Management
>     Tools 2.01 from MPW to THINK C.  THINK C always complains (illegal cast)
>     when constructions like:
>                (Str255) CtoPStr (etc...);
>      show up.  Does this typedef
>                          typedef unsigned char Str255[256]
>       in Types.h have something to do with the problem?? :-(

Yup.  Just write "(unsigned char *) CtoPStr(...)" instead.  You can cast
to a pointer but not to an array.

> 5.  This isn't a bug, but rather a complaint.  Shouldn't multi-file searches
>      automagically sift through #included files as well (and bring them up in
>      the search checklist dialog at the beginning)?  Would save a lot of time.

Quick way to do this:  put "Mac #includes.c" or whatever your precompiled
header's source file is into your project.  It'll add zero bytes of
object code, but you're guaranteed that clicking "Check all .h" in the
Multi-File Search dialog will really select _all_ .h files.
--
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 Sure, I subscribe to alt.sex, but I only read it for the articles...










Path: ucivax!gateway
From: [e-mail] ("Mark D. Nagel")
Subject: ARCHIVE: oops
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: CIGNA FIRST, Irvine, CA
Lines: 6
Date: 12 Aug 92 00:10:39 GMT
Phone: [phone]

I accidentally said that the sockets code is in the appl
subdirectory in the archives; it is in actuality located within the
code subdirectory; i.e., /mac/think-c/code/sockets-thinkc.hqx.
Sorry 'bout that!

Mark










Path: ucivax!gateway
From: [e-mail] (Danny Thomas)
Subject: Re: Please explain this trivial crash
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 56
Date: 12 Aug 92 01:32:59 GMT

>        Can someone explain to me why this simple code crashes with a bus
>error under Think C 5.0.2?
>
>******
>#include <stdio.h>
>
>#define ORDER 4
>
>void MatrixCopy(double a[ORDER][ORDER], double b[ORDER][ORDER])        /*Replaces
>a by b */
>{
>    register int i,j;
>
>    for(i=0;i<ORDER;i++)
>        for(j=0;j<ORDER; a[i][j] = b[i][j++]);
>
>/****
>If you replace the above with
>     for(j=0;j<ORDER;j++)
>         a[i][j] = b[i][j++];
>then all is well
>****/

>         a[i][j] = b[i][j++];
                          ^^
sure that is in the code that works, j is being incremented in for() as
well

I am suspicious of statements like these:
>> a[i][j] = b[i][j++]
is the j on the LHS the original value or post-incremented by the RHS?
I had a *brief* look at Harbison & Steel 3rd edition but couldn't find an
answer staring at me. In C an '=' is an binary expression operator and does
does not act as a sequence point. To quote H&S p207:
"In general, the compiler can rearrange the order in which an expression is
evaluated. The rearrangement may consist of evaluating only the arguments
of a function call, or the two operands of a BINARY OPERATOR (my emphasis),
in some particular order other than the obvious left-to-right order. ..."

To me, that implies the array indexing on the LHS could be done before or
after the RHS expression is evaluated. I'm open to correction on this
point, but if you are writing mathematical software, particularly when
roundoff, overflow, imprecision and other artifacts of floating-point
representations are important, you'd better get a good understanding of C's
evaluation order. Although expression rearrangement does allow for better
compiler optimizations, apparently it does cause problems with mathematical
software in particular. I seem to remember there are (ANSI?) working groups
on exploring ways to make C better for mathematical software.

PS if my guess was correct, you code could have been validly translated by
any C compiler so the last pass thru loop had a[] indexed out of bounds.
Whether THINK did this and why it caused an address error is, as textbooks
say, an exercise for the reader.

cheers,











Path: ucivax!gateway
From: [e-mail]
Subject: Weird Debugger activity...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 42
Date: 12 Aug 92 06:53:25 GMT


Forgive me those who are receiving this message twice to their simultaneous
subscriptions to the Think-C/TCL mailing groups.

I'm running a Mac SE/30 with 8 megs ram and think c 5.0.2 and latest TCL
version.

I'm using starter.pi project as a framework for my own application that will
work over the modem. However I am having problems debugging the code. It
seems the Debugger is adversely affecting my debugging efforts!

For example, when I try to run the program without the debugger it works
fine (except for the modem part which I am trying to debug). When I run
the debugger and "Go", somehow my Apps itsSwitchboard gets swiped from
under me. I tried a SS (Step Spy) in MacsBug on the address of the Handle
dereferencing itsSwitchboard, and then my Debugger started executing code
that wasnt supposed to be executed. In addition to that the Switchboard
didnt get swiped out from under me! (Does murphy's law reign in programming
or what?)

Some backround on my code: I've overridden the dokeydown method in my
subclass of Ctextedit, in order to send the key to the modem, but I
also call the inherited method as well.

When I comment out the code in the new method that handles sending the
key to the  modem, the code works fine then.

I have some Memory Manger calls in that method. I've been thinking that
the problem is simply that the memory manager is purging my Switchboard
so I did a HNoPurge in my IApp method but the problem persists.
I also thought I might be corrupting my heap but that doesnt explain
why the Switchboard is the only (and always the) one being NULLed.

And what does the dang Debugger have to do with it?

Should I have a 'backup' switchboard in case this happens?

Also, I have set the debugger to have a 500k partition and the project
to have a 512k partition. How could I run out of memory so fast?

Adam Skwersky
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Mark Nutter, Apple Support")
Subject: Re: Please explain this trivial crash
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: NETMAIL%"[e-mail]"
Lines: 64
Date: 12 Aug 92 12:14:16 GMT
X-Envelope-to: [e-mail]
X-Organization: Indiana University of Pennsylvania

>From:    NetMail%"[e-mail]"  "Danny Thomas" 11-AUG-1992 22:15:22.90
>To:    NetMail%"[e-mail]"
>CC:
>Subj:    RE: Please explain this trivial crash
>
>Return-path: <[e-mail]>
>Received: from ics.uci.edu by grove.iup.edu (PMDF #12462) id
> <[e-mail]>; Tue, 11 Aug 1992 22:15 EST
>Received: from ics.uci.edu by q2.ics.uci.edu id aa25907; 11 Aug 92 18:35 PDT
>Received: from USENET by q2.ics.uci.edu id aa25892; 11 Aug 92 18:33 PDT
>Date: 12 Aug 92 01:32:59 GMT
>From: Danny Thomas <[e-mail]>
>Subject: RE: Please explain this trivial crash
>To: [e-mail]
>Message-id: <[e-mail]>
>Newsgroups: fa.think-c
>
>>        Can someone explain to me why this simple code crashes with a bus
>>error under Think C 5.0.2?
>>
>>******
>>#include <stdio.h>
>>
>>#define ORDER 4
>>
>>void MatrixCopy(double a[ORDER][ORDER], double b[ORDER][ORDER])        /*Replaces
>>a by b */
>>{
>>    register int i,j;
>>
>>    for(i=0;i<ORDER;i++)
>>        for(j=0;j<ORDER; a[i][j] = b[i][j++]);
>>
>>/****
>>If you replace the above with
>>     for(j=0;j<ORDER;j++)
>>         a[i][j] = b[i][j++];
>>then all is well
>>****/

[stuff deleted]

>PS if my guess was correct, you code could have been validly translated by
>any C compiler so the last pass thru loop had a[] indexed out of bounds.
>Whether THINK did this and why it caused an address error is, as textbooks
>say, an exercise for the reader.
>
>cheers,
>

This is my guess, too:  Think C is evaluating the right hand side before the
left hand side.  Why not use the Assembler command to take a look at what code
the compiler is actually generating.  Even if you're not an assembly whiz, you
should be able to figure out whether the j++ is taking place before or after
the assignment.

-----------------------------------------------------------------------------
Mark Nutter                                  Internet: [e-mail]
Apple Support Manager                          BITNET: MANUTTER@IUP
Indiana University of Pennsylvania
G-4 Stright Hall, IUP
Indiana, PA 15705
"My horoscope says today is a bad day to be superstitious."
=============================================================================










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Weird problems with THINK C 5.0.2
Message-ID: <[e-mail]>
In-Reply-To: Mike Lyons's message of 11 Aug 92 19:10:27 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 29
Date: 12 Aug 92 13:53:39 GMT

In order for the #include popup and multi-file search through header
files to work, you must have already sucessfully compiled a source
file that #includes header files. For any source file, the list of
header files is constructed at the end of any successful compile.

In a similar fashion, the option-double click on identifiers will only
work if you've sucessfully linked your project, since THINK C uses the
link table to figure out which source file contains a given
identifier.

When you use #pragma once, make sure that you always use the same
capitalization when you #include a header file. Even though the Mac
file system is not case sensitive (for now, at least), THINK C
considers <stdio.h> and <StdIO.h> to be two different files.

>   (Str255) CtoPStr (etc...);

This cast is illegal because you can't cast to an array type. Instead
try:

    (StringPtr) CtoPStr( /* etc */ );

StringPtr is the "official" name for a pointer to a Str255.

    -phil
----
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Bob Miller)
Subject: Re: Smooth Animation & GNE/WNE - Is it possible?
Message-ID: <[e-mail]>
In-Reply-To: Your message of "01 Aug 92 16:44:39 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
X-Quote-Of-The: If lawyers had been present on Mount Sinai, the Ten
                Commandments would have twelve hundred amendments, all summing
                to the conclusion: The rich may ignore these rules, the poor
                will be hanged if they violate the smallest subordinate
                clause.                 -- Sigismundo Celine
Lines: 16
Date: 12 Aug 92 16:07:36 GMT

> Well, there's no easy way around it.  If you need ten minutes of solidly
> smooth animation at a constant 20 fps, then you're simply not going to
> be able to call WNE.
>
> However, there can be ways around it if your requirements are a little
> less stringent.  And it's very nice to know that downloads can go on
> while playing, so giving time to background processes _is_ a goal worth
> striving for.

BTW, it's more important for perceived smoothness that you keep things
moving at a constant rate than that you draw every frame.  You might
call GNE as usual, but whenever you draw an update check the current
time and calculate how far the various sprites have moved.

                    K<bob>











Path: ucivax!gateway
From: [e-mail]
Subject: Ptrs...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 12 Aug 92 17:44:23 GMT



In Inside the Macintosh V II chapter 9 (Serial Drivers):

"SerSetBuf specifies a new input buffer for the input driver having the
reference number refNum. SerBPtr points tothe buffer, and serBLen specifices
the number of bytes in the buffer. To restore the drivers default buffer,
call SerSetBuf with serBLen set to 0.

    Warning: You must lo new input buffer while its in use."

I'm using an allocated handle to a buffer and locking the handle so it
doesnt move. I use the dereferenced handle as the SerBPtr. Is this the only
safe way to go about this? IE could I just use a Ptr and Ptr = NewPtr(Size)?
Are Ptrs automatically locked? I couldnt find a routine in IM to lock
Ptrs. I'm having problems with bad pointers so I wanted to make sure I wasnt
doing any unecessary and potentially dangerous.


Also...the new SerBuf, is that where the FSRead PBRead, etc read their
data from? Or are is it simply the Buffer you pass to the Read function?

Also, do you think its a better idea to follow the CTB or use
the older Toolbox routines?

Adam










Path: ucivax!gateway
From: [e-mail]
Subject: Re: Please explain this trivial crash
Message-ID: <[e-mail]>
In-Reply-To: Your message of "11 Aug 92 21:33:49 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 60
X-Mts: smtp
Date: 12 Aug 92 19:13:49 GMT


Your message dated: 11 Aug 92 21:33:49 GMT

>        Can someone explain to me why this simple code crashes with a bus
>error under Think C 5.0.2?

You're not watching where your increments are occurring, I think.  The
assignment operator '=' in C is a right-to-left operator.  Therefore,
in the expression 'a[i][j] = b[i][j++]', if j is 2 when we start, i and
j++ (in b[i][j++]) are evaluated, j is incremented, b[i][2] is evaluated,
i and j are evaluated again (in a[i][j], but j is now 3) and finally, the
result from b[i][2] is assigned to a[i][3].  You get the bus error when
both i and j are ORDER.  (You may get it the first time j is ORDER; I
son't remember.)  Oh, you're not guaranteed a bus error; I'm not exactly
sure what happens.  But, you are looking at a bad memory address, so a
bus error is just one of many possibilities.  I think changing the code
to a[i][j++] = b[i][j] should fix it.  Try it.

In the second piece of code, you are incrementing j twice, with some very
interesting results.  You should get the same problem (but possibly not the
same error) if you add 1 to ORDER.  It has to do with whether or not ORDER
is even.

These problems should become evident if you examine the array a[][] in the
debugger after the call to MatrixCopy completes (or when you get the bus
error).  Unfortunately, Think C doesn't have a nice method for examining a
2-dimensional array.

BTW, if you are using nearly any level of optimization (such as using
registers across instructions; I'm not sure what the option is called),
you won't get any speed improvement out of packing the assignment and
the increment into the same statement.  You might as well make it easier
to read and debug by separating them.  Use:
    for(i=0;i<ORDER;i++)
        for(j=0;j<ORDER;j++)
            a[i][j] = b[i][j];
--Paul Franklin
>
>******
>#include <stdio.h>
>
>#define ORDER 4
>
>void MatrixCopy(double a[ORDER][ORDER], double b[ORDER][ORDER])
>    /*Replaces
>a by b */
>{
>    register int i,j;
>
>    for(i=0;i<ORDER;i++)
>        for(j=0;j<ORDER; a[i][j] = b[i][j++]);
>
>/****
>If you replace the above with
>     for(j=0;j<ORDER;j++)
>         a[i][j] = b[i][j++];
>then all is well
>****/
>}
>










Path: ucivax!gateway
From: [e-mail] (darin s morley)
Subject: the assignment operator
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 60
Date: 12 Aug 92 19:33:01 GMT

>       Can someone explain to me why this simple code crashes with a bus
>error under Think C 5.0.2?
>
>******
>#include <stdio.h>
>
>#define ORDER 4
>
>void MatrixCopy(double a[ORDER][ORDER], double b[ORDER][ORDER])        /*Replaces
>a by b */
>{
>    register int i,j;
>
>    for(i=0;i<ORDER;i++)
>        for(j=0;j<ORDER; a[i][j] = b[i][j++]);
>
>/****
>If you replace the above with
>     for(j=0;j<ORDER;j++)
>         a[i][j] = b[i][j++];
>then all is well
>****/
>}
...

>I am suspicious of statements like these:
>>> a[i][j] = b[i][j++]
>is the j on the LHS the original value or post-incremented by the RHS?
...

>This is my guess, too:  Think C is evaluating the right hand side before the
>left hand side. Why not use the Assembler command to take a look at what code
...

This is not a guess.

The assignment operator (=), according to the ANSI standard, operates from right
to left. It has to, because the value on the right hand side must be known
before it can be assigned to the left. Therefore, any expressions appearring on
the right will be evaluated before the left hand side is even considered. The
algorithmic decomposition of

    a[i][j] = b[i][j++]

would go something like this:

    get value of b[i][j]

    j' = j++

    store value of b[i][j] in a[i][j']

With i and j equal to zero the actual assignment would be:

    a[0][1] = b[0][0]

Notice that in the for-loop above which uses this assignment the error occurs
when a[i][ORDER] = b[i][ORDER - 1]. a[i][ORDER] is out of range.
---
[e-mail]










Path: ucivax!gateway
From: [e-mail] (James Meiss)
Subject: Re: Please explain this trivial crash
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 36
Date: 12 Aug 92 19:33:13 GMT

At 12 Aug 12:14 GMT, Mark Nutter, Apple Support wrote:

>>
>>>        Can someone explain to me why this simple code crashes with a bus
>>>error under Think C 5.0.2?

>>>    for(i=0;i<ORDER;i++)
>>>        for(j=0;j<ORDER; a[i][j] = b[i][j++]);

***stuff deleted****
>This is my guess, too:  Think C is evaluating the right hand side before the
>left hand side.  Why not use the Assembler command to take a look at what code
>the compiler is actually generating.  Even if you're not an assembly whiz, you
>should be able to figure out whether the j++ is taking place before or after
>the assignment.
>
>-----------------------------------------------------------------------------
>Mark Nutter                                  Internet: [e-mail]

        Thanks for all the help!. I found that in the following

    for(i=0;i<ORDER;v[i] = w[i++]);

    for(i=0;i<ORDER;v[i] = w[i],i++);

the first increments i before the assignment, so v[1] = w[0]. Only the
second works like one would want. Ah, the mysteries of C.


    James D. Meiss
    Program in Applied Mathematics                   [phone] office
    University of Colorado, Boulder 80309-0526            -4668 secretary
                                                                              -4066 FAX
    [e-mail]












Path: ucivax!gateway
From: [e-mail] (Bradford Castalia)
Subject: Re: Please explain this trivial crash
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 112
Date: 12 Aug 92 20:34:07 GMT
X-Envelope-to: [e-mail]


K&R (The C Programming Language, second edition) is very explicit about
the situation described. Here is a quote from pp. 53f:

"In any expression involving side effects, there can be subtle
dependencies on the order in which variables taking part in the
expression are updated.  One unhappy situation is typified by the
statement

    a[i] = i++;

The question is whether the subscript is the old value of i or the
new. Compilers can interpret this in differnt ways, and generate
different answers depending on their interpretation. The standard
intentionally leaves most such matters unspecified. When side effects
(assignment to variables) take place within an expression is left to
the discretion of the compiler, since the best order depends strongly
on machine architecture."

If you want portable and *reliable* code, avoid expressions that have
the possibility for ambiguity vis a vis order of expression
evaluation.

Bradford Castalia                      [e-mail]
Systems Manager                        [phone]
Planetary Image Research Laboratory    [phone]
Space Sciences Building, 429           LPL FAX: [phone]
University of Arizona
Tucson, Arizona  85721

----- Begin Included Message -----

From [e-mail] Wed Aug 12 06:13:14 1992
From: "Mark Nutter, Apple Support" <[e-mail]>
Subject: Re: Please explain this trivial crash
Newsgroups: fa.think-c
X-Vms-To: NETMAIL%"[e-mail]"
Date: 12 Aug 92 12:14:16 GMT
X-Envelope-To: [e-mail]
X-Organization: Indiana University of Pennsylvania
To: [e-mail]
Content-Length: 2256
X-Lines: 64

>From:    NetMail%"[e-mail]"  "Danny Thomas" 11-AUG-1992 22:15:22.90
>To:    NetMail%"[e-mail]"
>CC:
>Subj:    RE: Please explain this trivial crash
>
>Return-path: <[e-mail]>
>Received: from ics.uci.edu by grove.iup.edu (PMDF #12462) id
> <[e-mail]>; Tue, 11 Aug 1992 22:15 EST
>Received: from ics.uci.edu by q2.ics.uci.edu id aa25907; 11 Aug 92 18:35 PDT
>Received: from USENET by q2.ics.uci.edu id aa25892; 11 Aug 92 18:33 PDT
>Date: 12 Aug 92 01:32:59 GMT
>From: Danny Thomas <[e-mail]>
>Subject: RE: Please explain this trivial crash
>To: [e-mail]
>Message-id: <[e-mail]>
>Newsgroups: fa.think-c
>
>>        Can someone explain to me why this simple code crashes with a bus
>>error under Think C 5.0.2?
>>
>>******
>>#include <stdio.h>
>>
>>#define ORDER 4
>>
>>void MatrixCopy(double a[ORDER][ORDER], double b[ORDER][ORDER])        /*Replaces
>>a by b */
>>{
>>    register int i,j;
>>
>>    for(i=0;i<ORDER;i++)
>>        for(j=0;j<ORDER; a[i][j] = b[i][j++]);
>>
>>/****
>>If you replace the above with
>>     for(j=0;j<ORDER;j++)
>>         a[i][j] = b[i][j++];
>>then all is well
>>****/

[stuff deleted]

>PS if my guess was correct, you code could have been validly translated by
>any C compiler so the last pass thru loop had a[] indexed out of bounds.
>Whether THINK did this and why it caused an address error is, as textbooks
>say, an exercise for the reader.
>
>cheers,
>

This is my guess, too:  Think C is evaluating the right hand side before the
left hand side.  Why not use the Assembler command to take a look at what code
the compiler is actually generating.  Even if you're not an assembly whiz, you
should be able to figure out whether the j++ is taking place before or after
the assignment.

-----------------------------------------------------------------------------
Mark Nutter                                  Internet: [e-mail]
Apple Support Manager                          BITNET: MANUTTER@IUP
Indiana University of Pennsylvania
G-4 Stright Hall, IUP
Indiana, PA 15705
"My horoscope says today is a bad day to be superstitious."
=============================================================================


----- End Included Message -----











Path: ucivax!gateway
From: [e-mail] (Bob Miller)
Subject: Re: Please explain this trivial crash
Message-ID: <[e-mail]>
In-Reply-To: Your message of "12 Aug 92 01:32:59 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
X-Quote-Of-The: Open God read/write, to tell him my prayers.
                With synchronous I/O, He eases my cares.
                He buffers my troubles, and flushes His love.
                He's the OS of truth, the kernel above.
Lines: 13
Date: 12 Aug 92 20:57:18 GMT

> PS if my guess was correct, you code could have been validly translated by
> any C compiler so the last pass thru loop had a[] indexed out of bounds.
> Whether THINK did this and why it caused an address error is, as textbooks
> say, an exercise for the reader.

Your guess is correct.  It ain't legal to use j in the same expression
as j++.  As to why it bus errored, I'd guess that the next word past
the end of the array is a heap management pointer, and the bus error
occurred when that word was stepped upon.

Anyone want to confirm/deny MY guess?

                    K<bob>










Path: ucivax!gateway
From: [e-mail] (Danny Thomas)
Subject: Re: the assignment operator
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 68
Date: 12 Aug 92 22:13:41 GMT

deleting description of problem posed by James Meiss
<[e-mail]>
>>I am suspicious of statements like these:
>>>> a[i][j] = b[i][j++]
>>is the j on the LHS the original value or post-incremented by the RHS?
>...
>
>>This is my guess, too:  Think C is evaluating the right hand side before the
>>left hand side. Why not use the Assembler command to take a look at what code
>...
>
>This is not a guess.
>
>The assignment operator (=), according to the ANSI standard, operates from right
>to left. It has to, because the value on the right hand side must be known
>before it can be assigned to the left. Therefore, any expressions appearring on
>the right will be evaluated before the left hand side is even considered.

I've noticed a few people talk about left and right. Certainly that is the
way  people naturally think of these operators working, but left & right
refer to the associativity of operators, NOT the order in which their
operands are evaluated.
Eg because "a+=b!=c" doesn't have any brackets AND the operators have the
same precedence it could be interpreted as either "(a+=(b!=c)" or
"(a+=b)!=c". But because the operators on either side of b are right
associative, b is grouped with the != operator first, meaning the
expression is interpreted as "a+=(b!=c)".

    This morning I felt more inclined to crack open the ultimate reference,
 the ANSI Standard document, American National Standard X3.159-1989.
To quote the Assignment Operator, Section 3.3.16 page 54, line 10:
"Semantics
An assignment operator stores a value in the object designated by the left
operand. An assignment expression has the value of the left operand after
the assignment, but is not an lvalue. The type of an assignment expression
is the type of the left operand unless the left operand has qualified type,
in which case it is the unqualified version of the type of the left
operand. The side effect of updating the stored value of the left operand
shall occur between the previous and next sequence points.
  The order of evaluation of the operands is unspecified."

Reading standardese can be a little confusing, but I think the ANSI C
languange is fairly clear, at least compared to the few other standards
I've glanced at. It also comes with a Rationale, which while not a part of
the standard, can be read to grasp the intent, and why certain features
were/weren't added/removed.

The penultimate sentence seems to say that the timing of the actual update
is unspecified, but presumably must occur after both LHS & RHS have been
fully evaluated, but the last sentence  says the address on the LHS could
be computed before OR after the value of the expression on the RHS.

MORAL: be very careful writing expressions with side-effects

PS the parentheses in C do NOT control the order of evaluation, they
control how sub-expressions are grouped!
(a-b)+c can be evaluated either as (a+c)-b, or (a-b)+c or (c-b)+a
 all of which normally produce the same result in the absence of
under/overflow or floating point exceptions/roundoff/truncation.

cheers,
X500: @c=AU [I'm about to update VTHRC entries, soon...]
       @o=University of Queensland
        @ou=Physiology and Pharmacology Department
         @ou=Vision Touch and Hearing
          @cn=Danny Thomas
           @rfc822Mailbox=[e-mail]











Path: ucivax!gateway
From: [e-mail] (WES COVALT)
Subject: Scroll in Dialog
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 13 Aug 92 01:12:44 GMT

Hello,
     I want to use a scrolling text field in a modal dialog.  I
can get the control drawn (in a "user item") but I can't activate
it.  Using the debugger, I've noticed that neither theEvent.where
nor the local equivalent is within the control rect!  In fact,
if I click about 20 pixels to the LEFT of the contol it activates!
    Does any one have some hints for me?


Thanks much.

Wes Covalt
BITNET ADDRESS: P30WCC9@NIU
INTERNET ADDRESS:  [e-mail]











Path: ucivax!gateway
From: [e-mail] (WES COVALT)
Subject: Garbage in TEXT
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 13 Aug 92 01:24:56 GMT

Hello,
     I have stored some text into a TEXT (& STYL) resource and
I "insert" it into a TE field.  Most of the time, but not always
I get one or two garbage characters at the end of the text.  Once
in a while I get garbage in the middle of the text as well.

How do I get rid of this garbage?  I've played with changing the
strlen, but I still get the garbage characters.

Thanks much.

Wes Covalt
BITNET ADDRESS: P30WCC9@NIU
INTERNET ADDRESS:  [e-mail]











Path: ucivax!gateway
From: [e-mail] (John Draper)
Subject: Re:  ARCHIVE: oops
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 13 Aug 92 04:26:42 GMT

I actually pulled it off the "incoming" directory,  after I figured
out that the incoming directory is not printable (Restricted apparently),
but I "got" it anyway.   Nice piece of code,   It is most useful as
an example on how to use Networking code.

Thanx for the turn-on...
JD










Path: ucivax!gateway
From: [e-mail] ("Mark D. Nagel")
Subject: Re: ARCHIVE: oops
Message-ID: <[e-mail]>
In-Reply-To: Your message of Wed, 12 Aug 92 11:05:56 -0700.
     <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: CIGNA FIRST, Irvine, CA
Lines: 21
Date: 13 Aug 92 15:02:34 GMT
Phone: [phone]

In message <[e-mail]> you write:

    I actually pulled it off the "incoming" directory, after I
    figured out that the incoming directory is not printable
    (Restricted apparently), but I "got" it anyway.  Nice piece of
    code, It is most useful as an example on how to use Networking
    code.

Just so people are aware, ics.uci.edu recently changed the ftp
daemon to the same one used at wuarchive.wustl.edu and many other
sites these days.  (Also, they added an alias -- ftp.ics.uci.edu --
that everyone should use now just in case the archive machine
changes in the future).  This is why the incoming directory is
unreadable -- in that daemon, the incoming directory is supposed to
be a write-only dropoff point.  This adds a small amount of security
for those who ask people to drop off items (I guess random people
couldn't just scan stuff there and grab "private" things).  Anyway,
the files are still in the incoming directory, but won't be after
today.

Mark










Path: ucivax!gateway
From: [e-mail]
Subject: RE: Ptrs...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 13 Aug 92 16:01:52 GMT
X-Vmsmail-To: SMTP%"[e-mail]"


Pointers don't need to be locked, because there are fixed into memory. A
handle, a pointer to a pointer needs to be locked, because the memory
manager can move the block of data, and update the second pointer, while the
first pointer remains the same and valid.

I would use the CTB, just so you can have more that 2 serial ports if you
or your app's user has 'em.

Will










Path: ucivax!gateway
From: [e-mail] (John Draper)
Subject: Re:  Ptrs...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 13 Aug 92 16:21:54 GMT

I also want to know the answer to this,  so please CC your response to me as
well.

In particular,  does SerSetBuf set an "internal" buffer (One that is
different than the "Read" buffer)?

JD










Path: ucivax!gateway
From: [e-mail] (Jeffery Garner)
Subject: AppleEvents: Receiver wants TargetID of Sender
Message-ID: <[e-mail]>
Content-Type: TEXT/PLAIN; charset=us-ascii
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 45
Date: 15 Aug 92 03:05:33 GMT


Hello!  I'm a little confused about a lot of the structures for AppleEvents.
I've written my own custom event called PING, and the sending application
is able to send PING to the receiver.  The receiver beeps when it gets
PING.  No problem.

Now suppose the receiver wants to know who the sender is (TargetID is fine),
so that the Receiver can "register" the sender's name in a list (of
TargetIDs) so the Receiver can later initiate its own AppleEvents back
to the Sender at a later time...

The Question:  How does the receiver of an AppleEvent take apart the
AppleEvent structure in such a way as to get a TargetID out of it?

I tried doing the following, but it didn't work:

pascal OSErr HandlePING(AppleEvent *theAppleEvent, AppleEvent *reply,
              long myRefCon)
{
    OSErr         myErr;
    TargetID    myTarget;
    DescType    typeCode;
    Size        actualSize;

    myErr = AEGetParamPtr(theAppleEvent,keyAddressAttr,typeTargetID,
        &typeCode,(Ptr) &myTarget, sizeof(TargetID), &actualSize);
    if (myErr) return (myErr);

    myErr = RequiredCheck(theAppleEvent);
    if (myErr) return (myErr);

    SysBeep(1);
    return (noErr);
}

the first myErr returns an error.  It can't find the desc record or something.

Any thoughts would be appreciated!

Jeff Garner
Shoestring Software Products
Internet: [e-mail]
          [e-mail]












Path: ucivax!gateway
From: [e-mail] (AARON BARNETT)
Subject: 2 questions
Message-ID: <[e-mail]>
Content-transfer-encoding: 7BIT
MIME-version: 1.0
Newsgroups: fa.think-c
X-VMS-To: TOE::IN%"[e-mail]"
Lines: 9
Date: 15 Aug 92 03:43:52 GMT
X-Envelope-to: [e-mail]

hello,
 1: i want to do something similar to DragGrayRgn, but I want to drag
a whole rgn, like colors and all as if you had picked the _thing_ up.
is there a trap that has evaded my finding. it seems to me to be a mac
thing cus menus come and go without causing an update event.

 2: I need sin() and cos() but don't want ansi. is it in sane.

thanks in advance










Path: ucivax!gateway
From: [e-mail] ("Jeff D. Garner")
Subject: Re: AppleEvents: Receiver wants TargetID of Sender
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: TEXT/PLAIN; charset=us-ascii
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 81
Date: 15 Aug 92 23:46:08 GMT


Well, I finally found an answer to my problem, in Apple's Q&A stack of
all places...  ( I keep forgetting to look in places like that!).

Here's the solution for those who are interested:

-------------------------------------------------

How can I identify the sender of an Apple event?

If your application is just sending a reply, it should not be creating an
Apple event or calling AESend. Instead, it should stuff the response
information into the reply event in the Apple event handler, as shown on
page 6-50 of Inside Macintosh Volume VI. The Apple Event Manager takes
care of addressing and sending the event.

To find the target ID or process serial number of the sender of an Apple
Event, use AEGetAttributePtr to extract the address attribute, as follows:


retCode := AEGetAttributePtr(myAppleEvent, keyAddressAttr,
  typeWildCard, senderType, @senderBuffer, sizeof(senderBuffer),
  senderSize)

The senderBuffer can later be used with AECreateDesc to create an address
to be passed to AESend. The buffer should be at least as large as data
type TargetID. See Inside Macintosh Volume VI, page 5-22, for a
description of
TargetID.



On 15 Aug 1992, Jeffery Garner wrote:

>
> Hello!  I'm a little confused about a lot of the structures for AppleEvents.
> I've written my own custom event called PING, and the sending application
> is able to send PING to the receiver.  The receiver beeps when it gets
> PING.  No problem.
>
> Now suppose the receiver wants to know who the sender is (TargetID is fine),
> so that the Receiver can "register" the sender's name in a list (of
> TargetIDs) so the Receiver can later initiate its own AppleEvents back
> to the Sender at a later time...
>
> The Question:  How does the receiver of an AppleEvent take apart the
> AppleEvent structure in such a way as to get a TargetID out of it?
>
> I tried doing the following, but it didn't work:
>
> pascal OSErr HandlePING(AppleEvent *theAppleEvent, AppleEvent *reply,
>               long myRefCon)
> {
>     OSErr         myErr;
>     TargetID    myTarget;
>     DescType    typeCode;
>     Size        actualSize;
>
>     myErr = AEGetParamPtr(theAppleEvent,keyAddressAttr,typeTargetID,
>         &typeCode,(Ptr) &myTarget, sizeof(TargetID), &actualSize);
>     if (myErr) return (myErr);
>
>     myErr = RequiredCheck(theAppleEvent);
>     if (myErr) return (myErr);
>
>     SysBeep(1);
>     return (noErr);
> }
>
> the first myErr returns an error.  It can't find the desc record or something.
>
> Any thoughts would be appreciated!
>
> Jeff Garner
> Shoestring Software Products
> Internet: [e-mail]
>           [e-mail]
>
>












Path: ucivax!gateway
From: [e-mail] (Jim Lynch)
Subject: Here is a portion of the about think-c file.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 16 Aug 92 16:19:11 GMT

One request: if someone submits a question on something that seems simple to
you, please remember that it will seem simple to many of the other 425+
subscribers to the list.  Please reply to the sender directly unless you
feel it is warranted to broadcast the reply.  The person who submitted the
question is urged to followup at some time in the future with a summary of
responses, so others who might be interested can see what the solution was.
This simple rule will prevent much of the chaff that is present on many
mailing lists and newsgroups.











Path: ucivax!gateway
From: [e-mail]
Subject: File Searching in HFS
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-Original-To: [e-mail], KE1RKEN
Lines: 10
Date: 17 Aug 92 17:53:45 GMT

I hope someone can help me with code for getting a program to search
for a file. I know it's name. I know what folder it's in. I just don't
know where that folder is. I don't want to use a dialogue box.

Perhaps this is a bit much. Still, it all reduces to getting the list
of files or folders in a givin volume, I think. I can't find the routine
for doing this. The SF routines must use this in the dialogue box.
Where can I find it?

Many Thanks, Bob










Path: ucivax!gateway
From: [e-mail]
Subject: Shall we have "simple" messages?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 17 Aug 92 21:38:26 GMT

>One request: if someone submits a question on something that seems simple to
>you, please remember that it will seem simple to many of the other 425+
>subscribers to the list.  Please reply to the sender directly unless you
>feel it is warranted to broadcast the reply.  The person who submitted the

Hmm... well, sometimes I learn something from these, and the rest of
the time, I just delete it -- no problems.

Perhaps it's a lot harder for some other people?

What do people feel about it?

Ian










Path: ucivax!gateway
From: [e-mail] (AARON BARNETT)
Subject: Re: simple
Message-ID: <[e-mail]>
Content-transfer-encoding: 7BIT
MIME-version: 1.0
Newsgroups: fa.think-c
X-VMS-To: TOE::IN%"[e-mail]"
Lines: 5
Date: 17 Aug 92 23:31:05 GMT
X-Envelope-to: [e-mail]

>Hmm... well, sometimes I learn something from these, and the rest of
>the time, I just delete it -- no problems.

agreed











Path: ucivax!gateway
From: [e-mail] (Erik Svensson FOA2)
Subject: File Searching in HFS
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 17 Aug 92 17:53:45 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 18 Aug 92 07:17:19 GMT

Why don't you use the system 7 routines for this?
There's a call PBCatSearch (I think it was, don't have IM VI available right
now) that'll find you your file.

Erik Svensson            Research Officer
Guided Weapons Division        National Defense Research Establishment (FOA)
Stockholm            Sweden

net.address:     [e-mail]

"I've got LOT's of common sense. I just choose to ignore it." -- Calvin










Path: ucivax!gateway
From: [e-mail] (Wolfgang Naegeli)
Subject: Mailer problems
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 40
Date: 18 Aug 92 15:26:25 GMT

        Reply to:   Mailer problems
Starting about July 15 for some two weeks we had severe problems with
ics.uci.edu opening but not closing SMTP connections when sending us messages.

After all SMTP listener sockets on our Mail*Link SMTP gateway were tied up, we
were unable to recieve any incoming messages from anywhere. We had no telling
of what had happened since outgoing traffic was not affected. We had to reboot
frequently when we got dinged by the administrator of our central mail router
who complained that large mail queues were building up for us.

Did any other think-c recipients experience similar problems?

On 8/13 Mark wrote:
> ics.uci.edu recently changed the ftp daemon to the same one used at
> wuarchive.wustl.edu and many other sites these days.

Could that change have had something to do with our problems? When exactly was
that change made?

Of course, as usual, all of this happened while I was out of town. Starnine
Tech Support sent us a diagnostic tool, but as mysteriously as the problems had
started, they disappeared. Fortunately we were able to capture the last
occurrence and after Starnine analyzed the postmortem and fingered ics.uci.edu
I wrote to its postmaster, but got his reply that he had not noticed anything
unusual.  Only last week, I realized that ics.usi.edu actually is the host
think-c comes from.

Even though we are problem-free again, we would like to get to the bottom of
this in hopes of preventing any possible future recurrence since it affected
many of our e-mail users.

Any facts, clues, hints, and observations will be greatly appreciated.

Wolfgang N. Naegeli
University of Tennessee & Oak Ridge National Laboratory
Internet: [e-mail]  (best)       Bitnet: wnn@ornlstc
QuickMail (QM-QM): Wolfgang Naegeli @ 615-574-4510
Phone: [phone]       Fax: [phone] (OrchidFax)












Path: ucivax!gateway
From: [e-mail] (Eric Slosser)
Subject: 2 questions
Message-ID: <[e-mail]>
In-Reply-To: AARON BARNETT's message of 15 Aug 92 03:43:52 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 4
Date: 18 Aug 92 19:48:47 GMT


For your question about dragging a whole object around, look in
Knaster and Rollin's book for some very nice sample code.











Path: ucivax!gateway
From: [e-mail] ("Edward J. Huff")
Subject: Smooth Animation vs. QuickTime
Message-ID: <[e-mail]>
Content-transfer-encoding: 7BIT
Newsgroups: fa.think-c
Lines: 11
Date: 19 Aug 92 02:02:53 GMT
X-Envelope-to: [e-mail]

There has been some discussion of smooth animation but no one has
mentioned quicktime.  Isn't smooth animation the purpose of quicktime?
(I have a Quadra 950 here which came with quicktime, but I haven't
used it yet...  I noticed that there is a quicktime directory at
ftp.apple.com which contains the quicktime INIT, identical to the
one which came on my system).
--
Edward J. Huff   [e-mail]   [phone]
Keck Laboratory for Biomolecular Imaging
NYU Chemistry Deptartment, 31 Washington Place, New York NY 10003











Path: ucivax!gateway
From: [e-mail] (Wade Williams)
Subject: Great job Symantec!
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 56
Date: 19 Aug 92 14:30:56 GMT

Someone who is taking an online C course complained last night that THINK C
takes up more room than her DOS C files.  She was doing the classic Hello
World and had the following sizes:

Hello World project (with ANSI lib)  64K
Hello World built app                20K

Her DOS project was

Hello.c    2K
Hello.exe  8K (this was after deleting Hello.obj)

I explained to her that if she removed objects from her THINK C project,
that was the same as deleting Hello.OBJ on the DOS side.

That made the score:
Hello World project   8K
Hello World app       20K

So, you end up with 28K on Macintosh vs. 10K on DOS.

I went on to explain that the DOS machine can pretty much just write to the
screen whereas the Mac has to draw a window, handle events, etc.  That
accounts for the extra 10K.  I also explained that Smart linking includes a
whole file even if only one function is referenced (that is correct,
right?).  I explained that if she really wanted to take the time, she could
copy just the functions she needed and paste those into her project and
remove the ANSI library, making for a much smaller project.  However, the
convenience makes that not worth the trouble.

Then I examined the built Hello World app.  A 20K app had a movable window,
handled events, had a functioning menubar, supported clipboard operations
and supported backgrounding. I was also able to get the app to run stabily
in 55K of RAM.

Can you imagine how much code it would take to create a DOS or Windows
program that did the same thing?  I'd be willing to bet a whole lot more
than 20K.

I know that most of the credit goes to Apple for providing such a great
Toolbox, but I'd like to congratulate Symantec as well.  It really amazes
me that it only takes 20K to do all the things that the Hello World app
does.  I know it doesn't sound like much, but if you sit down and think
about it, it's really a lot.

Good job Symantec!


-------------------------------------------------------------------
Wade Williams                        "One likes to believe in the freedom
User Services Specialist          of music, but glittering prizes and
Academic Computing Services    endless comprimises shatter the
Auburn University                 illusion of integrity."
[e-mail]                          (N. Peart of Rush)
--------------------------------------------------------------------











Path: ucivax!gateway
From: [e-mail]
Subject: Re: Smooth Animation vs. QuickTime
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 19 Aug 92 15:12:32 GMT

>There has been some discussion of smooth animation but no one has
>mentioned quicktime.  Isn't smooth animation the purpose of quicktime?
>(I have a Quadra 950 here which came with quicktime, but I haven't
>used it yet...  I noticed that there is a quicktime directory at
>ftp.apple.com which contains the quicktime INIT, identical to the
>one which came on my system).

A quadra is about the only mac that can do quick time smoothly so thats not
an option.

Matt
_____________________________________________________________________
   Matthew Xavier Mora                   |  The keeper of the UMPG
   SRI International                     |  [e-mail]
   [sent using Eudora 1.3b46]            |  [e-mail]
_____________________________________________________________________
"You give good headgames, your tongue is so strange, caught in these
 backstage chains." _Crashed_ by Slik Toxik











Path: ucivax!gateway
From: [e-mail] (AARON BARNETT)
Subject: terrain generator
Message-ID: <[e-mail]>
Content-transfer-encoding: 7BIT
MIME-version: 1.0
Newsgroups: fa.think-c
X-VMS-To: TOE::IN%"[e-mail]"
Lines: 3
Date: 19 Aug 92 19:46:22 GMT
X-Envelope-to: [e-mail]

i need to generate some 3-d terrain randomly (mountains vally) I can
handle displaying it, but I havn't a clue how to generate it.
anyone...










Path: ucivax!gateway
From: [e-mail] (Paul Franklin)
Subject: Re: terrain generator
Message-ID: <[e-mail]>
In-Reply-To: Your message of "19 Aug 92 19:46:22 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 26
X-Mts: smtp
Date: 20 Aug 92 00:43:17 GMT


Your message dated: 19 Aug 92 19:46:22 GMT
>i need to generate some 3-d terrain randomly (mountains vally) I can
>handle displaying it, but I havn't a clue how to generate it.
>anyone...

This is really a math problem.  What you want is a function f(x,y)
that will give you a 3-D terrain.  Try

f(x,y) = 10/(1+x*x+y*y)

Now, you should be able to combine these.  For example,

f(x,y) = 10/(1 + x*x + y*y) - 5/(1 + (x-4)*(x-4) + (y+3)*(y+3))

Try plotting that one.  The more terms, the more hills/valleys.
Looking at the valley in the second example, the -5 is its height (the
negative makes it a valley), and x-4=0, y+3=0 gives you the center of
the valley (4,-3).  You could also make it something other than a
round hill (oval?) by multiplying (y+3) by 2.  Just play with it, and
see what combinations seem to fit in with what you want.

I'm pretty sure I got the function right; I took it from memory and
just tried a few test cases in my head.

--Paul Franklin










Path: ucivax!gateway
From: [e-mail] (Peter Miller)
Subject: Re: terrain generator
Message-ID: <[e-mail]>
In-Reply-To: Your message of 19 Aug 92 19:46:22 +0000.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 20 Aug 92 02:14:42 GMT


AARON BARNETT <[e-mail]> writes:
> i need to generate some 3-d terrain randomly (mountains vally) I can
> handle displaying it, but I havn't a clue how to generate it.
> anyone...

Try Eric Haines' SPD package for testing renderers.
One of the scenes is fractal mountains.

The comp.graphics FAQ lists several archive sites,
if you don't have usenet or ftp, try sending email to
    [e-mail]
with a subject of "help".  This archive also has SPD.

Regards
Peter Miller.










Path: ucivax!gateway
From: [e-mail] (Dana S Emery)
Subject: Re: terrain generator
Message-ID: <[e-mail]>
In-Reply-To: Your message <[e-mail]> of 19 Aug 92
 19:46:22 GMT
Content-Type: TEXT/plain; charset=US-ASCII
Newsgroups: fa.think-c
Lines: 17
Date: 20 Aug 92 04:33:40 GMT

>   i need to generate some 3-d terrain randomly (mountains
>   vally) I can handle displaying it, but I havn't a clue
>   how to generate it. anyone...


If this was for a game, you might be able to do with random choice of cleverly
predesigned 'tiles', for an overhead view you could also make them rotateable.

Other than that it is time to break out the acm graphics journals and dig into
some serious fractal hackery.  I would attempt to discern some rules as to what
makes mountains grow, and then use suitable randomization of that to establish a
skeleton which would be fleshed out useing fractal textureing.  Unfortunately
this is a wee bit above my present math skills.  Hope you are targeting some
nice crunchy hardware.

Dana S Emery <[e-mail]>











Path: ucivax!gateway
From: [e-mail] (Bob Miller)
Subject: Re: terrain generator
Message-ID: <[e-mail]>
In-Reply-To: Your message of "19 Aug 92 19:46:22 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
X-Quote-Of-The: I sure like to succeed, but you can't get away from the fact
                that failure gives you a great liberty.  -- Jack Crabb
Lines: 78
Date: 20 Aug 92 16:12:21 GMT

> i need to generate some 3-d terrain randomly (mountains vally) I can
> handle displaying it, but I havn't a clue how to generate it.
> anyone...

You can generate random fractal terrain pretty easily.

The basic idea is to start with a square, subdivide it, into quarters,
and then randomly perturb the center point.  Now you have
four smaller squares, so repetitively subdivide them.  As the squares
get smaller, the perturbations get smaller too.

For example,  (I just typed this in, so it probably has a bug or two
and a few syntax errors...)

#define LOGN 5
#define N (1 << LOGN)

int elevation[N + 1][N + 1];    /* 33x33 elevation grid, ranges from */
                /* -1000 to 1000 */

int random(int n)
{
    /* return random integer uniformly distributed between 0 and n - 1; */
}

/* average_elev returns average elevation among four points. */

int average_elev(minx, miny, maxx, maxy)
{
    return (elevation[minx][miny] + elevation[minx][maxy] +
        elevation[maxx][miny] + elevation[maxx][maxy]) / 4;
}

/*
 *  subdivide() recursively subdivides a square area in elevation
 *  into smaller squares, perturbing each one's center.
 */
void subdivide(int minx, int miny, int maxx, int maxy, int perturbation_size)
{
    int midx = (minx + maxx) / 2;
    int midy = (miny + maxy) / 2;
    int avg_elev;
    int half_pert = perturbation_size / 2;

    if (maxx <= minx + 1)
    {    /* This is a 1x1 square; don't subdivide any further */
    return;
    }

    avg_elev = average_elev(minx, miny, maxx, maxy);
    elevation[midx][midy] = random(perturbation_size) - half_pert + avg_elev;

    subdivide(minx, miny, midx, midy, half_pert);
    subdivide(midx, miny, maxx, midy, half_pert);
    subdivide(minx, midy, midx, maxy, half_pert);
    subdivide(midx, midy, maxx, maxy, half_pert);
}

/*
 *  generate_terrain() generates, in the elevation array, a randomly
 *  perturbed N+1 x N+1 elevation map.
 */

void generate_terrain(void)
{
    /* Pick four corners at random heights. */

    elevation[0][0] = random(1000) - 500;
    elevation[0][N] = random(1000) - 500;
    elevation[N][0] = random(1000) - 500;
    elevation[N][N] = random(1000) - 500;

    subdivide(0, 0, N, N, 500);
}

You get the idea, don't you?

                    K<bob>










Path: ucivax!gateway
From: [e-mail]
Subject: Summaries yes, multiple replies no
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 20 Aug 92 22:47:22 GMT

Hi, everyone.

Recently I posted a message saying that I sometimes benifited from the many
replies to a problem, and had no trouble deleting stuff that didn't interest
me and so I would like to see them continue.

However, several people have pointed out that the listowner has guidlines
saying that this should not be done -- instead, summaries should be posted
by the original querient at the end of his/her search.

Since this is the listowner's policy, yes, we should follow it. So I retract
my earlier statements.

Thanks for your patience.

Ian










Path: ucivax!gateway
From: [e-mail]
Subject: In TCL, file is locked?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 21 Aug 92 12:39:59 GMT



I am working with TC 5.0.2 and TCL 1.1.2. When I open a file (document)
and I try to open it again I would like to be able to issue an alert
saying something like " This file is being used..." . The Open method in
the class DataFile uses FailOSError with HOpen as argument. If there is
an error from HOpen, FailOSError handles it. This led me to belive that I
have to subclass FailOSError to handle a particular error in HOpen. However,
I doubt it and I am sure there is something simpler that can be done.

So, my question is: Is there a way to check if a file is being used or locked
(using TCL) before sending the Open message?
Any help on this will be appreciated.

Thanks.

Rodrigo.

[e-mail]










Path: ucivax!gateway
From: [e-mail] (Ryan Richard Koopmans)
Subject: remove me
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 21 Aug 92 16:25:42 GMT

Please remove me from the mailing list.










Path: ucivax!gateway
From: [e-mail]
Subject: Re:HFS file searching
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-Original-To: [e-mail], KE1RKEN
Lines: 21
Date: 21 Aug 92 16:53:58 GMT

My thanks to all those who responded to my query about how to search
for a file within a folder, whose location is not precisely known.
Several respondents recomended use of PBGetCatInfo in Inside Mac VI.
Another, with warning of the task ahead, recomended Inside Mac IV.

Further traipsing about the internet ended in Apple.com (ftp:130.43.2.3)
in /dts/mac/sc was found the file: sc-018-stdfilesample.hqx. It appears
to be extensive in a variety of calls to the file system. It is, of course,
written in Pascal using MPW. There are some cryptic indications in the
file that a C version was considered or perhaps even implemeted. Such
a file cannot be found, unfortunately.

So, does anyone know of this .c file? If not, if some brave individual
were to try to translate this program into THINK C, would he/she be able
to post it to the net for public consumption without violating Apple's
rights (which are indicated to be reserved). I would ponder (with
great trepidation) such an effort, but not for just my consumption.
The main file is some 65 pages in length and I am not a Pascal programmer.

Best Wishes,
Bob Kennedy










Path: ucivax!gateway
From: [e-mail] (WES COVALT)
Subject: GetResource( 'TEXT', id) problem
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 22 Aug 92 23:51:40 GMT

I have been using GetResource() to get 'TEXT' resources for various
dialog screens.  I have been getting "funny" characters at the end
of these text files.  I release the resource  and dispose of the
handle after I use the resource (and show a particular screen).
   I know that the problem is at GetResource becuase when I look
at the text pointed to with the debugger, the text is all mine
except for the these few characters.  Sometimes these characters are
from another of my text resources that I had just shown.  Sometimes.

   Do I have to initialize something?  Do I need to clear memory?
Is there another way of storing large amounts of text (with style)
and not use a PICT?










Path: ucivax!gateway
From: [e-mail]
Subject: c on mac
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
X-Mts: smtp
Date: 24 Aug 92 03:30:15 GMT

I'm in the process of scanning c++ language to buy for my mac. Can you,
or one of your subscribers, tell me why I should (or shouldn't) buy Think-c?

Jan Dockx    "[e-mail]"
Leuven, Belgium
Europe










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: Arashi (Project STORM) source code
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 26
Date: 24 Aug 92 03:36:03 GMT


------- Forwarded Message

Date:    Thu, 20 Aug 92 21:55:10 +0300
From:    [e-mail]
To:      [e-mail]
Subject: Arashi (STORM) source code

The complete source code and documentation set for the Arashi (Project STORM)
game has been placed in the /incoming directory. Please read the included
read me file.

If you are interested in writing arcade games for the Macintosh, you should
definitely at least take a look.

The file is quite large (over 800KB).

    Juri Munkki
    [e-mail]

------- End of Forwarded Message

[saved as: /mac/think-c/code/Arashi_Source.cpt.bin; 840K]

  [NOTE: This is a BINARY submission; remember to use binary mode when]
  [retrieving this file.                          ]










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: sockets library removed
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 9
Date: 24 Aug 92 03:47:11 GMT

The author of the sockets library notified me that the version I
placed in the archives is not for distribution, so I removed it.
The real version should be ready real soon now, so please, be
patient and don't send him questions about the copy you got from the
archives.

Thanks!

Mark










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: XCMD/XFCN calling conventions
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 24 Aug 92 10:06:19 GMT

Could some kind soul provide a quick description of what XCMD's and XFCN's
look like in terms of source? I want to add some externals to the
MicroPhone II scripting system, but there's no information about the
calling conventions. I assume they're just A4-global code resources with
pascal argument passing, but I don't know anything more than that. A more
complex question is how to generate and return strings into MicroPhone II,
but I'd better ask SVC tech support directly about that...

Nick.











Path: ucivax!gateway
From: [e-mail] (Rolf Staflin)
Subject: XCMD/XFCN calling conventions
Message-ID: <[e-mail]>
In-Reply-To: Nick Rothwell's message of 24 Aug 92 10:06:19 GMT <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 16
Date: 24 Aug 92 11:27:52 GMT


>From: Nick Rothwell <[e-mail]>
>Newsgroups: fa.think-c
>Date: 24 Aug 92 10:06:19 GMT
>
>Could some kind soul provide a quick description of what XCMD's and XFCN's
>look like in terms of source?

  I have no idea, but please let me know if you get any good answers (if
you summarize to think-c, I'll get it that way)
  Thanks in advance and good luck!
/Rex
---------
Rolf Staflin              SnailMail: SICS, Box 1263, S-164 28 KISTA, Sweden
Email: [e-mail]        Phone: [phone]  Telex: 812 6154 7038 SICS
Telefax: [phone]  Voice: "Vakna, Roffe!"  Mizar: >greet Zarquon










Path: ucivax!gateway
From: [e-mail] (Rolf Staflin)
Subject: Speeding up the graphics...
Message-ID: <[e-mail]>
In-Reply-To: Rolf Staflin's message of Mon, 24 Aug 92 13:27:41 +0200 <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 26
Date: 24 Aug 92 14:24:39 GMT


  (Sorry about my last post - didn't see the CC field (again).)
Anyway, I've been meaning to ask this for quite a while, but I suspected it
might be done already.

  Do you know any (safe) ways to improve graphics performance under system 6?
I'm writing a game (lunar lander style with variations) on my old Plus, and
I'm having trouble with the frame rate. I've been doing odd Mac hacks for the
last three years, so I'm fairly familiar with the OS and toolbox, but I
have only read I.M. I-IV, and they don't give that much advice in the
matter. Games like Crystal Quest and Continuum manage to get quite a lot of
performance out of the Plus, but my program bogs down with only two or
three "sprites". Somebody spoke of using waitNextEvent() in stead of
GetNextEvent() -- is that a good way to gain performance? CopyBits is
pretty slow -- do I have to write my own routines for bitmaps (I've started
on a poor man's CopyBits in assembler, but I haven't worked on it since
last christmas)?
  All input along these lines would be greatly appreciated. I'm thinking of
compiling some sort of document with speed hints for the archives. Has this
been done already? I'll summarize here, so e-mail me any responses
(remember the CC field :-)).
/Rex
---------
Rolf Staflin              SnailMail: SICS, Box 1263, S-164 28 KISTA, Sweden
Email: [e-mail]        Phone: [phone]  Telex: 812 6154 7038 SICS
Telefax: [phone]  Voice: "Vakna, Roffe!"  Mizar: >greet Zarquon










Path: ucivax!gateway
From: [e-mail]
Subject: sending a 'writ' appleevent
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 25 Aug 92 02:01:13 GMT



hello folks,

i'm trying to find a way to send a "Force Write" message to another
application. that is, i want to send someone a 'writ' event (class 'sect')
to force it to update a publisher, to which i subscribe. it's a common
appleEvent which many apps use, but only when Apple sends it.  for
my app to send it involves one problem: getting the right value
for the sectionHandle which i want published.

if i send the 'writ' event with my copy of the sectionHandle, the other
app doesn't find a match for it, since we have different copies of the
information.  so how can i get a copy of its sectionHandle? or, how
else can i get it to publish NOW!?

i can assume that the other app is running on the same machine, by the
way.

thanks for any help,
:jeff bellsey
[e-mail]











Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: ANSI-A4, ANSI-small
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 26 Aug 92 11:10:30 GMT

The TC5 manual says that ANSI-A4 is a subset of ANSI-small since file
operations aren't available in an A4-globals library (or words to that
effect). Is there a reason for this? I'd like to do some file munging in
XCMDs/XFCNs, and have built myself an A4 ANSI-small for that reason. Why
would fopen(), fclose() and the like not work? (I haven't tried it yet,
since I still haven't figured out the XFCN calling conventions fully...)

Nick.











Path: ucivax!gateway
From: [e-mail] (Danny Thomas)
Subject: Re: ANSI-A4, ANSI-small
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 143
Date: 26 Aug 92 23:20:12 GMT

Nick Rothwell <[e-mail]> writes:
>The TC5 manual says that ANSI-A4 is a subset of ANSI-small since file
>operations aren't available in an A4-globals library (or words to that
>effect). Is there a reason for this? I'd like to do some file munging in
>XCMDs/XFCNs, and have built myself an A4 ANSI-small for that reason. Why
>would fopen(), fclose() and the like not work? (I haven't tried it yet,
>since I still haven't figured out the XFCN calling conventions fully...)
>
>Nick.


Hello Nick, to repost a reply I sent here a month ago; I think the recipe
that follows is fairly accurate in what I did with a multi-segment code
resource for an Igor XOP (eXternal OPeration, analagous to HC XCMD/XFCNs
but I don't know how the interface compares), but I would like to hear how
other people go, plus any other comments:

cheers,
X500: @c=AU [I'm about to update VTHRC entries, soon...]
       @o=University of Queensland
        @ou=Physiology and Pharmacology Department
         @ou=Vision Touch and Hearing
          @cn=Danny Thomas
           @rfc822Mailbox=[e-mail]


[repost follows]

Zach Kessin <[e-mail]> writes
>Is there a way to use the ansi file operstions fprinf(), fopen() etc
>in a code resource? Better yet a way to get a fake prinf() that would
>send output to a text buffer?
>
>I think I could fake it if I had to...
>                            ...But I'd rather not have to.

well Zach, I recently went through this in writing an XOP (external module)
for the Igor graphing/analysis program. In my case there were several other
ANSI facilities I wanted to use (eg strftime()) which amounted to rather
more work than simply faking fopen() etc. To quote from the comments I
wrote at the time:

/*
 *             NOTES ON THINK C ANSI LIBRARY IN XOPs
 *
 *  ANSI A4 is missing quite a few ANSI functions, perhaps because they
 *  aren't needed by most things you do in the A4 world, but with some of
 *  them it isn't as simple as just including the file in the project:
 *    in the case of time.c, it simply has arrays of strings with
 *    an initializer of literal strings constants. These are OK in
 *    a single-segment code resource, but not in a multi-segment project.
 *    The workaround is to use a function to perform the initialization.
 *
 *  PROBLEMS WITH STDIO FUNCTIONS
 *  have to include at least
 *    alloc, fread, fseek, getc, iomisc, stdio
 *  the FILE structs are allocated statically, but the buffers are
 *    malloc'd and free'd by fclose() and other functions. It is
 *    important that the buffers are free'd upon exit from the XOP
 *    including premature panic exits.
 *  I think malloc should be OK with CODE resources though they
 *    can't be used from interrupt routines, such as drivers
 *  my approach is to remove the _atexit_stdio() function register
 *  and and move the stdio_exit() call to the CLEANUP message below.
 */

//  time.c modified because it had static string initialization
//  so this routine needs to be called before using ANY ANSI time stuff!!
void  init_time_routines(void);
//  in the THINK ANSI stdio library, this routine was registered
//  as an at_exit function. This was causing a problem, see notes below.
void  stdio_exit(void);



     *=*=*=*=*=*=*=*=*=*=*=* RECIPE *=*=*=*=*=*=*=*=*=*=*=*=

make a copy of time.c called my_ANSI_time.c and place this conditional
around the definitions of day/month names already there (or simply replace
them)

#if 1

static char *dayname[7];  //  had string initializers
static char *monthname[12];  //  had string initializers

void  init_time_routines(void);  //  new function

void  init_time_routines(void)
{
    dayname[0] = "Sunday";     dayname[1] = "Monday";    dayname[2] =
"Tuesday";
    dayname[3] = "Wednesday";  dayname[4] = "Thursday";  dayname[5] =
"Friday";
    dayname[6] = "Saturday";
    monthname[0]  = "January";   monthname[1] = "February";
    monthname[2]  = "March";     monthname[3] = "April";
    monthname[4]  = "May";       monthname[5]  = "June";
       monthname[6]  = "July";       monthname[7]  = "August";
    monthname[8]  = "September";     monthname[9] = "October";
    monthname[10] = "November";   monthname[11] = "December";
}

#else


... proprietary Symantec code


#endif

so at the start of your code YOU will have to call init_time_routines() to
initialise the month names.



make a copy of fopen.c called my_ANSI_fopen.c

Comment out the call to __atexit_stdio() at the end of __open()
Excise the "static" qualifier on the prototype declaration at the top of
the file, as well as the actual function definition of stdio_exit(). This
means that at the end of your program YOU will have to explicitly call
stdio_exit() to clean up the open files.
NB check comment block above, the cleanup has to be done on premature exits
too! (which was why THINK at_exit() registered the function)

In my case I made up a code-resource project with the following unmodified
THINK modules and built it as a library
arith.c, atoi.c, bufio.c, ctype.c, errno.c, fwrite.c, mem.c, printf.c,
scanf.c, stdio.c, str.c, strn.c & ungetc.c
PS on reflection, maybe this was the original THINK A4 library?

In the actual project for my XOP I included this library (8026 bytes) plus
alloc.c, fread.c, fseek.c, getc.c, iomisc.c my_ANSI_fopen.c &
my_ANSI_time.c
Mind you these could have been compiled in a second library.


That's all that I seem to have written down. All I know is that it seemed
to work for me but would be grateful to hear of other comments notably why
the at_exit() stuff didn't work. I believe MPW doesn't have the same
restrictions on multi-segment A4 stuff as THINK does.











Path: ucivax!gateway
From: [e-mail] (WALSHAG)
Subject: ModalDialog Abuse...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 26 Aug 92 23:50:12 GMT

Let me first say:
   I *know* I shouldn't be doing this.
   I should be using the Window Manager instead.
   I have read Tech. Note #203.

however....

I must have a movable dialog in a specific situation, and (for the
time being) it can not be a movable-modal.   I am using a custom
filter procedure with ModalDialog, where I need to be sure that a
"slice of the processing pie" is given to other applications.  This
is necessary because apps in the background must have an opportunity
to update the area my dialog has been dragged over.

Currently, my dialog erases all underlying graphics.   My dialog is used in an
FKEY, not within an application.  This seems to complicate things.

At one point I had solved this, but that was some time ago and I can
no longer find the code.  Now I'm kicking myself...

Does anyone have suggestions?  I am under the gun to finish this and
would appreciate any help.

many thanks,
Aaron Walsh
[e-mail]











Path: ucivax!gateway
From: [e-mail] (WALSHAG)
Subject: Pixel-editor source?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 27 Aug 92 00:58:01 GMT


I am going to be creating a pixel-editor, one that can create a color image to
be saved as a pixel pattern (ppat).   Since I'll be creating the editor from
scratch (ugh), I would be like at least the skeleton of an existing one to
build upon.

Last I heard there was source to a color icon editor on MouseHole (MacTutor's
BBS).  I just tried to connect, but the number is in the process of being
changed so I'm out of luck!

Does anyone have  C source (procedural or TCL) for a color pixel-editor of any
type, which I might augment for my own use?


I would appreciate any leads,

Aaron Walsh
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: ANSI-A4, ANSI-small
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 27 Aug 92 10:28:44 GMT

Needless to say, I didn't catch this thread a month ago, since I didn't
think I'd be trying to do A4-global file I/O at any stage. I'll try to keep
my thing single-segment, but it looks as if I still have to deal with exit
conditions properly. I'll have a look over your code: ta.

I'd dispense with the ANSI I/O modules and do it all with file manager
calls, except that MicroPhone II is going to deliver entire path names to
me, and I don't think FSOpen() and the like will take full path names. The
easiest way might be to lift the path name resolution code out of
ANSI-small and do it myself, just using the File Manager...

Nick.











Path: ucivax!gateway
From: [e-mail] (AARON BARNETT)
Subject: Pixel-editor source? me too.
Message-ID: <[e-mail]>
Content-transfer-encoding: 7BIT
MIME-version: 1.0
Newsgroups: fa.think-c
X-VMS-To: TOE::IN%"[e-mail]"
Lines: 7
Date: 27 Aug 92 18:16:26 GMT
X-Envelope-to: [e-mail]

hey fellas,
  im interested in pixel editor code also.  id really like to get that
color icon editor mentioned in the original note.  thats closer to what
i need.

thanks











Path: ucivax!gateway
From: [e-mail] (inei)
Subject: Pointer arithmetic evaluation bug in THINK C?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 59
Date: 28 Aug 92 08:37:49 GMT


Given the following program:

char    line[] = "Hello";
main()
{
        char    *cp1 = line;
        char    *cp2 = &line[4];
        int             len = cp2 - cp1;

        printf ("diff = %d\n", cp2 - cp1);
        printf ("len = %d\n", len);
}

I get the following output from THINK C:

diff = 0
len = 4

but the following from my SUN:

diff = 4
len = 4

Take another example - a restatement of K&R's book (page 98):

mystrlen (s)
        char    *s;
{
        char    *p = s;

        while (*p != '\0')
                p++;
        printf ("%d\n", p-s);
        return (p-s);
}

char    line[] = "hello";
main()
{
        printf ("length of line: %d\n", mystrlen(line));
}

Output from THINK C:

0
length of line: 5

Output from UNIX:

5
length of line: 5

Has anyone encountered this problem?  Is there a patch beyond 5.0.2?

Mail:  Nick Nei, Computing Science Dept.,
       Glasgow Univ., 17 Lilybank Gardens,
       Glasgow G12 8QQ, UK.  Tel: [phone] x 5457
ARPA:  [e-mail] USENET: [e-mail]










Path: ucivax!gateway
From: [e-mail] (inei)
Subject: PBUnmountVol and UnmountVol problem...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 28 Aug 92 08:37:56 GMT


Basically,

If I have file-sharing on,

    UnmountVol ("\pvolume:", 0);

fails and returns -47.  Seasoned mac users will also remember that with
file-sharing enabled, you cannot change volume names.

If I don't have file-shring on, UnmountVol() and PBUnmountVol() works
fine.

Can anyone help?

Mail:  Nick Nei, Computing Science Dept.,
       Glasgow Univ., 17 Lilybank Gardens,
       Glasgow G12 8QQ, UK.  Tel: [phone] x 5457
ARPA:  [e-mail] USENET: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Pointer arithmetic evaluation bug in THINK C?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 25
Date: 28 Aug 92 11:05:44 GMT

>char    line[] = "Hello";
>main()
>{
>        char    *cp1 = line;
>        char    *cp2 = &line[4];
>        int             len = cp2 - cp1;
>
>        printf ("diff = %d\n", cp2 - cp1);
>        printf ("len = %d\n", len);
>}
>
>I get the following output from THINK C:
>
>diff = 0
>len = 4

Erm, hmm, thinks...

BING! "cp2 - cp1" is a long. "len" is an int. The first printf is bogus
without a "%ld".

What prize have I won? :-)

Nick.











Path: ucivax!gateway
From: [e-mail] (Paul Potts)
Subject: Pointer arithmetic evaluation bug in THINK C?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 33
Date: 28 Aug 92 14:46:19 GMT


This isn't a bug. Your code is making the non-portable assumption that the
sizeof (int) == sizeof (char*)

Suppose you have:

        char    *cp1 = line;
        char    *cp2 = &line[4];
        int             len = cp2 - cp1;

        printf ("diff = %d\n", cp2 - cp1);
        printf ("len = %d\n", len);

Where:

cp1 = 0x5555AAA0
cp2 = 0x5555AAA4

len = 0x5555 - 0x5555

I'm willing to bet that this is the problem.

The workaround:  either use the long type to do your pointer arithmetic,
or set the option int = 4 bytes in THINK C, and rebuild the libraries
(you will have to rebuild the ANSI library).

I am willing to bet this might be the problem. In the second case, the
problem might be that you are using the %d specifier to print a long value,
when it expects an int; in UNIX they are generally the same. Give this a
shot (and let me know if I'm totally off base).

-Paul Potts-
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Mark D. Nagel")
Subject: ADMIN: problems with new ftp daemon on ftp.ics.uci.edu
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: CIGNA FIRST, Irvine, CA
Lines: 9
Date: 28 Aug 92 15:34:11 GMT
Phone: [phone]

Apparently there have been a number of people having troubles
getting through to the archives on ftp.ics.uci.edu.  The new daemon
they installed there seems to be timing out when attempting to do a
reverse name lookup for the connecting host.  I've spoken with the
support staff there and they are attempting to find a solution.  If
you are having problems, please be patient; I'll stay on top of it
until they find some way of making it work properly...

Mark










Path: ucivax!gateway
From: [e-mail] (aaron barnett)
Subject: #include<QDOffScreen.h>
Message-ID: <[e-mail]>
Content-transfer-encoding: 7BIT
MIME-version: 1.0
Newsgroups: fa.think-c
X-VMS-To: TOE::IN%"[e-mail]"
Lines: 1
Date: 28 Aug 92 17:55:17 GMT
X-Envelope-to: [e-mail]

where do i find documentation on this and other non-standard libs?










Path: ucivax!gateway
From: [e-mail] (Steve Williams)
Subject: RE: Pointer arithmetic bug in THINK C?
Message-ID: <0095FC49.39770000.3959@GTEWD>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 106
Date: 28 Aug 92 17:58:22 GMT

Nick Nei asked [e-mail]

>>> Given the following program:
>>>
>>> char    line[] = "Hello";
>>> main()
>>> {
>>>         char    *cp1 = line;
>>>         char    *cp2 = &line[4];
>>>         int             len = cp2 - cp1;
>>>
>>>         printf ("diff = %d\n", cp2 - cp1);
>>>         printf ("len = %d\n", len);
>>> }
>>>
>>> I get the following output from THINK C:
>>>
>>> diff = 0
>>> len = 4
>>>
>>> but the following from my SUN:
>>>
>>> diff = 4
>>> len = 4
>>>
>>> Has anyone encountered this problem?  Is there a patch beyond 5.0.2?

Nick Rothwell <[e-mail]> responds:

>> BING! "cp2 - cp1" is a long. "len" is an int. The first printf is bogus
>> without a "%ld".
>>
>> What prize have I won? :-)

Paul Potts <[e-mail]> adds:

> This isn't a bug. Your code is making the non-portable assumption that the
> sizeof (int) == sizeof (char*)


Neither of these two explanations is entirely correct in an ANSI C compiler,
although Nick Rothwell has pointed out what happened in THINK C.  Paul's answer
is misleading, because what matters is not whether sizeof(int) ==
sizeof(char*), but rather what variable type is required to hold a difference
of two pointers (which could be different than that required to hold an int or
a pointer).

In ANSI C, the difference between to pointers (i.e., the value of (cp2 - cp1)
in the first example) is defined to have type 'ptrdiff_t', which is basically
like 'size_t', except that it must be signed.  The difference between two
pointers is *ALWAYS* the number of elements between the objects (which is why
you cannot take the difference of two 'void *' pointers, and also why it is
illegal to subtract two pointers to different types).

int main (int argc, char * argv)
{
  float        array[10];
  float *    fp1 = &array[0];
  float *    fp2 = &array[1];
  char *    cp1 = &array[0];
  char *    cp2 = &array[1];

  printf ("%ld\n", (long) (fp2 - fp1));  // will print '1'
  printf ("%ld\n", (long) (cp2 - cp1));  // should print sizeof(float) usually 4
  printf ("%ld\n", (long) (cp2 - fp1));     // illegal, should not compile
}

The trouble is that after having gone to all the trouble to define that pointer
differences are of type ptrdiff_t, the ansi standard does not require that
ptrdiff_t be the same as long, nor did they define a printf format specifier
for printing a ptrdiff_t or a size_t.

THINK C is an ANSI compliant compiler (finally) but it uses 16-bit 'int'
variables by default.  'size_t' is 'unsigned long' and 'ptrdiff_t' is 'long'
no matter how the "4-byte ints" compiler option is set.  Basically Nick Nei's
original code gets viewed by the compiler as:

char    line[] = "Hello";
main()
{
  char *    cp1 = line;
  char *    cp2 = &line[4];
  int           len = cp2 - cp1;
  ptrdiff_t    dummy1 = cp2 - cp1;

  printf ("diff = %d\n", dummy1);
  printf ("len = %d\n", len);
}

And since ptrdiff_t is the same as long, you can see that the %d format
specifier needs to be %ld (Nick Rothwell wins that prize).  The zero that THINK
C prints is really the high 16-bits of the 32-bit word.  Your SUN probably
still does not have an ANSI C compiler, and like most UNIX C compilers, makes
the assumption that 'int' is the same as 'long', so you can get away with
writing some amazingly unportable C.  UNIX C code is peppered with things like:

    long    num_of_things;

    printf ("There are %d things\n", num_of_things);

This kind of code breaks on almost any machine where sizeof(int) !=
sizeof(long).  Worse things happen with pointers, because most UNIX C compilers
let you get away with the assumption that sizeof(int) == sizeof(void*).

Hope this explanation helps:
Steve Williams










Path: ucivax!gateway
From: [e-mail]
Subject: SFGetDirectory on FKEY
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 3
Date: 28 Aug 92 19:56:55 GMT
X-Vmsmail-To: SMTP%"[e-mail]"

I tried to use a standard file box to get a directory in an FKEY and it
bombed on me... any ideas why? (ie: I'm hoping it's buggy code...)











Path: ucivax!gateway
From: [e-mail] (Danny Thomas)
Subject: RE: Pointer arithmetic bug in THINK C?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 39
Date: 28 Aug 92 22:12:54 GMT

two points:
I wish more compilers would verify format strings against the variable
argument list in printf/scanf functions, both in number and type. This
should work well since the vast majority of format strings are (I imagine)
literal constants.
My preference would be for not enough arguments to rate as a fatal error,
but type-mismatches or too many arguments to only generate a warning.
Problems with printf are normally easier to track down because the result
is usually only too visible, but scanf problems can be more subtle - hands
up those who have forgotten to pass addresses instead of values!
    Coincidentally, I'm just finishing up a repackaging of sprintf() and
sscanf() functionality for the visual, dataflow language Prograph. These
versions will perform type and arity checking for their inputs, and their
outputs (including the %n conversion in printf) will generate data values
of the specified type - being dataflow, you don't have variables to store
values in.


As Steve Williams notes, it is disappointing that ANSI did not define
format conversion operators for the types they invented for portability -
ptrdiff_t, size_t. One kludgy workaround makes use of literal string
concatenation:

#ifdef VAX
#define PTRDIFF_T_CONV "d"
#else
#ifdef MAC
#define PTRDIFF_T_CONV "ld"
#endif
#endif

...
    diff = p1 - p2;
    printf("pointer difference = %6" PTRDIFF_T_CONV, diff);
...


cheers,











Path: ucivax!gateway
From: [e-mail]
Subject: Re: Pointer arithmetic bug in THINK C?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: MSSCC::IN%"[e-mail]"
Lines: 47
Date: 29 Aug 92 02:44:19 GMT
X-Envelope-to: [e-mail]


Danny Thomas <[e-mail]> writes:

>two points:
>I wish more compilers would verify format strings against the variable
>argument list in printf/scanf functions, both in number and type. This
>should work well since the vast majority of format strings are (I imagine)
>literal constants.

The compiler doesn't know anything about printf/scanf (other than what is
in the #include'd prototypes).  To make it know would be a departure from
the general philosophy of c ("so what" you may say).  I think it would even
be a violation of the standard; I should be able to name my own function
'printf', see that it gets linked to my code, and pass it anything I want to.

>As Steve Williams notes, it is disappointing that ANSI did not define
>format conversion operators for the types they invented for portability -
>ptrdiff_t, size_t. One kludgy workaround makes use of literal string
>concatenation:
>
>#ifdef VAX
>#define PTRDIFF_T_CONV "d"
>#else
>#ifdef MAC
>#define PTRDIFF_T_CONV "ld"
>#endif
>#endif
>
>...
>    diff = p1 - p2;
>    printf("pointer difference = %6" PTRDIFF_T_CONV, diff);
>...

You don't need to do anything so kludgy.  Just typecast the variable
whose value is being printed, e.g.:

...
    diff = p1 - p2;
    printf("pointer difference = %d", (int) diff);
...

which should work on any machine (unless, obviosly, the difference is so large
that it can't fit into an int).  You could also use %ld and typecast
to long.

-Josh Cherry











Path: ucivax!gateway
From: [e-mail] (Paul Potts)
Subject: RE: Pointer arithmetic bug in THINK C?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 31 Aug 92 12:36:06 GMT


Gentle readers

Terribly sorry to have "misled" anyone

(Steve Williams <[e-mail]> writes:
>> Paul's answer
is misleading, because what matters is not whether sizeof(int) ==
sizeof(char*), but rather what variable type is required to hold a difference
of two pointers (which could be different than that required to hold an int or
a pointer).

For those of you that I "misled," I apologize (dripping sarcasm). For the
rest of you bright enough not to need Professor William's agonizingly
detailed explanation of pointers, the differences between them, and the
types thereof, I hope I was of some help.











Path: ucivax!gateway
From: [e-mail] (WALSHAG)
Subject: Pixel-editor & 'ppat' resources
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 31 Aug 92 14:37:28 GMT

For the record, I was unable to find the source to an existing pixel editor.

Instead I wrote a utility which allows the user to "snap" a section of the
screen.  This section is converted to my own pixMap, which I then use in the
creation of a pixPat (which is the structure stored in a 'ppat' resource).

All is well and good until I try to save my pixPat to disk with AddResource().
At this point, the resource becomes corrupted & is unreadable.










Path: ucivax!gateway
From: [e-mail] (WALSHAG)
Subject: Pixel editor & ppat con't
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 31 Aug 92 14:52:31 GMT

[Sorry for the break in messages.  My habit of command-s to save periodically
while working backfires in MS-Mail:command-s in MS-Mail is send, not save]

At any rate....

The 'ppat' I have saved to disk is now corrupted.  I have tried several things
to remedy this.  I also tried saving it to a resource other than 'ppat', just
in case something was awry with the 'ppat' data structure.  No luck.

I am no stranger to saving custom resources, so this should be straight forward
& simple.  An easy test to see what I am talking about is to read in an
existing 'ppat' using either GetResource() or GetPixPat() and  then try to save
it out as a new one using DetachResource(), AddResource() & WriteResource().
This approach works fine unless you *change* the pixPat now in memory.  Once
you try to save out the changed resource, it is once again corrupted.

Incredibly frustrating, as this project would be done if I could just save  my
pixPat to disk!

Any ideas?

Aaron Walsh
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Paul Potts)
Subject: Pointer arithmetic evaluation bug in THINK C?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 109
Date: 31 Aug 92 16:00:03 GMT


All right. For clarity's sake, here are the reasons I am angry:
I originally wrote:

>This isn't a bug. Your code is making the non-portable assumption that the
sizeof (int) == sizeof (char*)

Steve Williams wrote:

>Paul's answer
>is misleading, because what matters is not whether sizeof(int) ==
>sizeof(char*), but rather what variable type is required to hold a difference
>of two pointers (which could be different than that required to hold an
>int or a pointer).

It is potentially unsafe to cast the difference between two pointers
to an int. ANSI can take care of itself with ptrdiff_t, but it can't
guard against the assumption made in the first example that the
difference between the pointers (of type ptrdiff_t) will fit into
an int. ptrdiff_t must be potentially as large as a generic
pointer (although, of course, in the first case the difference
will only be a few bytes). The size of ptrdiff_t is tied to the
size of a generic pointer. I can conceive of machine architectures
in which they aren't the same - but on a machine like the Mac,
they must be.

However, what do we see down near the end of Steve William's long
posting?

>Your SUN probably
>still does not have an ANSI C compiler, and like most UNIX C compilers, makes
>the assumption that 'int' is the same as 'long', so you can get away with
>writing some amazingly unportable C.....
>
>Worse things happen with pointers, because most UNIX C compilers
>let you get away with the assumption that sizeof(int) == sizeof(void*).

On the Mac, Pointers are all the same size. sizeof (void*) is
the same as sizeof (char*), so my original statement applies here.
Surprise! In addition, Williams' explanation that
"The difference between two pointers is *ALWAYS* the number of
elements between the objects (which is why you cannot take the
difference of two 'void *' pointers, and also why it is
illegal to subtract two pointers to different types)." is correct,
but needless - in THINK C, the char type is one byte, and so
the difference between ten chars in memory is the same as the
difference between two generic pointers that point to memory
ten bytes apart (although one can't take the difference between
pointers to void).

I also wrote:

>In the second case, the
>problem might be that you are using the %d specifier to print a long value,
>when it expects an int; in UNIX they are generally the same. Give this a
>shot (and let me know if I'm totally off base).

Williams was enjoying jumping on my initial response so much, that
he didn't notice this portion of my posting. He added:

>And since ptrdiff_t is the same as long, you can see that the %d format
>specifier needs to be %ld (Nick Rothwell wins that prize).  The zero that >THINK C prints is really the high 16-bits of the 32-bit word.

Thus, I supplied two
comments which turned out to be somewhat applicable according to
Williams' own posting: one is ignored, and regarding the other,
I am just told "Paul's answer is misleading."
One-upmanship at work; sheer pedantry. Williams is too busy handing
out prizes to consider that this is an open discussion, and the
purpose of my posting was to try to provide a couple of useful
suggestions, not trumpet my knowledge of the innards of C.

I also received correction from Bradford Castalia, which I will
accept because it was graciously done. Bradford writes:

>I'll take you up on your bet! I think you're wrong that in your example
>you would have:
>
>        len = 0x5555 - 0x5555
>
>In fact the C language guarantees that the pointer subtraction will
>give a correct result (I've checked K&R on this).

And he is right: I was incorrect about the way the conversion would
take place, maintaining the low-order bits. However, Bradford also
wrote:

>You are right about the %d specifier to printf...

I suspected a possible problem here, because I have had problems
with printf myself, especially when I was just starting out with
C. For my IBM-compatible programming work I now use C++, and I'm
happily using streams, which are type-safe and go much further
to protect the programmer against possible pitfalls like the
long-to-int conversion.

Bradford continues:

>You lose the bet, but you guessed right in the end. We'll call it a
>wash ;-)

Bradford Castalia                      [e-mail]

Thanks.

I hope this helps explain why I was somewhat irate in my posting
earlier today. Please, everyone. This forum is not a competition!
We are here to help one another. I will also try to be less
sensitive in the future.










Path: ucivax!gateway
From: [e-mail] (Ramesh Chandak)
Subject: Appmaker and THINK C question ?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 31 Aug 92 22:30:04 GMT

HI folks,

I have a question about how to Import PICT resources into Appmaker and
define them as part of a tool palette that I wish to create for this
application.  Is there any way I can do this using AppMaker or do I
have to write my own C code to do it ?

Is there any public domain source code available that will help me do this ?
Any help in this regard shall be much appreciated.  Thanx.

- Ramesh